Documentation Index
Fetch the complete documentation index at: https://resources.devweekends.com/llms.txt
Use this file to discover all available pages before exploring further.
🚀 What is Low Level Design?
Low Level Design (LLD) is the bridge between system architecture and working code. While High Level Design (HLD) answers “what components do we need?”, LLD answers “how do we implement each component with clean, maintainable, extensible code?”. Think of it this way: HLD is the city plan that decides where to place hospitals, schools, and roads. LLD is the architectural blueprint for each individual building — the floor plan, wiring, plumbing, and structural engineering. Both are essential, but LLD is where abstract ideas become concrete, testable, production-grade software.Classes & Objects
Design Patterns
Clean Code
📊 Course Stats
6+
23
5
45 min
✅ Prerequisites
Before diving into LLD, make sure you’re comfortable with:Programming Fundamentals
Programming Fundamentals
- Variables, functions, loops, conditionals
- Basic data structures (arrays, dictionaries, sets)
- At least one OOP language (Python, Java, C++, TypeScript)
Basic OOP Concepts
Basic OOP Concepts
- Classes and objects
- Methods and attributes
- Basic inheritance
🎯 Learning Path
Follow this structured 4-week journey to master LLD:Week 1: Master OOP Fundamentals
OOP Concepts
OOP Deep Dive
BankAccount class with proper encapsulationWeek 2: Learn SOLID Principles
SOLID in Practice
SOLID Deep Dive
Week 3: Study Design Patterns
Design Patterns
UML Diagrams
Week 4: Practice Case Studies
Parking Lot
Vending Machine
LRU Cache
Movie Ticket
Chess Game
Elevator
🏆 Why LLD Matters for Interviews
LLD rounds are make-or-break at top tech companies. They test if you can translate high-level ideas into working, maintainable, production-ready code. Unlike algorithm rounds that test raw problem-solving, LLD rounds reveal how you think about software at scale — your instincts about where to draw class boundaries, when to reach for a pattern, and how to communicate trade-offs. This is the round that separates engineers who write code from engineers who design systems.Object-Oriented Thinking
Pattern Recognition
Code Quality
Trade-off Analysis
Extensibility
Edge Case Handling
What Interviewers Actually Evaluate
| Criteria | Weight | What They Look For |
|---|---|---|
| Requirement Gathering | 10% | Do you ask the right clarifying questions? |
| Class Design | 25% | Are your classes well-named, single-purpose, properly related? |
| Design Patterns | 20% | Do you apply appropriate patterns without over-engineering? |
| Code Quality | 20% | Is your code clean, readable, and following conventions? |
| SOLID Principles | 15% | Does your design follow SOLID? Can you explain violations? |
| Communication | 10% | Did you explain your thinking throughout the process? |
📋 The LLD Interview Framework (45 min)
Master this framework to ace any LLD interview:- Overview
- Phase 1: Requirements
- Phase 2: Core Design
- Phase 3: Deep Dive
- Phase 4: Discussion
📚 Common LLD Interview Problems
By Difficulty Level
🟢 Beginner (Start Here)
🟢 Beginner (Start Here)
🟡 Intermediate (Build Skills)
🟡 Intermediate (Build Skills)
| Problem | Key Concepts | Case Study |
|---|---|---|
| Elevator System | State pattern, Scheduling | View → |
| Chess Game | Polymorphism, Command | View → |
| Hotel Booking | Reservation, Concurrency | View → |
| Movie Ticket Booking | Seat allocation, Transactions | Start → |
| Food Delivery App | Multiple actors, State | Coming Soon |
| Online Shopping Cart | Order flow, Discounts | Coming Soon |
🔴 Advanced (Master Level)
🔴 Advanced (Master Level)
| Problem | Key Concepts | Case Study |
|---|---|---|
| Ride Sharing (Uber/Ola) | Matching, Real-time, Location | Coming Soon |
| Social Media Feed | Observer, Timeline, Caching | Coming Soon |
| Stock Exchange | Order matching, Concurrency | Coming Soon |
| Splitwise | Graph, Debt simplification | Coming Soon |
| Rate Limiter | Token bucket, Sliding window | Coming Soon |
By Design Pattern Focus
| Pattern | Best Practice Problems |
|---|---|
| Strategy | Payment processing, Shipping methods, Pricing |
| Factory | Vehicle creation, Notification channels |
| Observer | Stock alerts, Order status, Movie Booking |
| State | Order lifecycle, Elevator, Vending Machine |
| Decorator | Coffee shop, Pizza toppings, Permissions |
| Singleton | Database connection, Configuration, Logger |
| HashMap + DLL | LRU Cache, Browser History |
🔧 Quick Reference: Core Concepts
The Four Pillars of OOP
SOLID Principles One-Liners
| Principle | Rule | Example |
|---|---|---|
| Single Responsibility | One class, one reason to change | Order shouldn’t send emails |
| Open/Closed | Extend, don’t modify | Add new PaymentMethod, don’t edit old ones |
| Liskov Substitution | Subtypes are substitutable | Penguin shouldn’t break Bird.fly() |
| Interface Segregation | Small, focused interfaces | Readable vs ReadableWritable |
| Dependency Inversion | Depend on abstractions | Inject Database, not PostgreSQL |
Pattern Quick Reference
📖 Case Studies
🅿️ Parking Lot System
Beginner Strategy Pattern
📚 Library Management
Beginner CRUD
🛗 Elevator System
Intermediate State Pattern
♟️ Chess Game
Intermediate Polymorphism
🏨 Hotel Booking
Intermediate Transactions
🏧 ATM System
Beginner State Pattern
💡 Pro Tips for LLD Interviews
Start Simple, Then Extend
Start Simple, Then Extend
Think Out Loud
Think Out Loud
Ask Clarifying Questions
Ask Clarifying Questions
Know Your Patterns
Know Your Patterns
Consider Extensibility
Consider Extensibility
Handle Edge Cases
Handle Edge Cases
🎯 Quick Links
OOP Concepts
SOLID Principles
Design Patterns
UML Diagrams
Interview Cheat Sheet
Case Studies
Interview Deep-Dive
An interviewer asks: 'Walk me through how you approach an LLD problem you have never seen before.' What is your framework?
An interviewer asks: 'Walk me through how you approach an LLD problem you have never seen before.' What is your framework?
- I follow a four-phase framework. First, I spend about five minutes on requirements: clarifying scope, identifying actors, and asking what is explicitly out of scope. This prevents over-engineering.
- Second, I spend twenty minutes on core design. I list nouns from the problem statement, which become classes. I list verbs, which become methods. I then map relationships: is-a for inheritance, has-a for composition, and uses for dependency. I sketch a class diagram with key attributes and methods only — no boilerplate.
- Third, I spend fifteen minutes on implementation. I code the happy path first, then layer in design patterns where they solve a real problem (not to show off). I mention edge cases even if I do not fully implement them.
- Fourth, I spend five minutes discussing trade-offs: why I chose one approach over another, how the design handles new requirements, and where I would add caching, logging, or concurrency controls in production.
- The key insight is that I start simple and iterate. An interviewer would rather see a clean three-class design that you evolve than a ten-class over-engineered design that you cannot explain.
You are designing a system and the interviewer says: 'Your design has a God class. How would you fix it?' How do you respond?
You are designing a system and the interviewer says: 'Your design has a God class. How would you fix it?' How do you respond?
- A God class is one that has accumulated too many responsibilities. The fix is systematic application of the Single Responsibility Principle. I would identify each distinct “reason to change” in the class — for example, if an OrderManager handles data persistence, email notifications, pricing calculations, and PDF generation, those are four separate reasons to change.
- I would extract each responsibility into its own class: OrderRepository for persistence, NotificationService for emails, PricingService for calculations, InvoiceExporter for PDF generation. The original class becomes a thin coordinator (sometimes called a Facade) that delegates to these focused services.
- The practical benefit is testability. A God class with five responsibilities requires mocking five different external systems to unit test. Five focused classes each require mocking at most one or two dependencies.
- In an interview, I would physically draw the extraction on the whiteboard: show the original class, draw arrows to the new classes, and explain how each extracted class has a single, clear reason to change.
Explain how you would use UML in a 45-minute LLD interview. What would you draw, and what would you skip?
Explain how you would use UML in a 45-minute LLD interview. What would you draw, and what would you skip?
- I draw a class diagram as my primary artifact. I start with three to five core classes showing just the class name and the relationship arrows. Then I progressively add key attributes and method signatures as the conversation evolves. I use proper UML notation for relationships: filled diamond for composition, open diamond for aggregation, dashed arrow with open triangle for interface implementation, and solid arrow with open triangle for inheritance.
- I annotate multiplicity on every relationship. Saying “Customer has Orders” is vague. Writing “1 to 0..*” is precise and shows the interviewer I think about cardinality.
- I would skip sequence diagrams unless the interviewer specifically asks about a complex interaction flow (like a checkout process with multiple services). I would also skip use case diagrams entirely — they are too high-level for LLD.
- What I would not skip: visibility markers (+ for public, - for private, # for protected). Getting these right shows I am thinking about encapsulation at the design level, not just at the code level.
An interviewer asks: 'Which five design patterns would you prioritize for LLD interviews, and why those five?'
An interviewer asks: 'Which five design patterns would you prioritize for LLD interviews, and why those five?'
- Factory, Strategy, Observer, State, and Singleton. These five cover roughly eighty to ninety percent of LLD interview scenarios.
- Factory is essential because almost every system needs to create objects without coupling to concrete types. When the interviewer asks “how would you add a new vehicle type,” Factory is the answer.
- Strategy is the workhorse pattern for the Open/Closed Principle. Whenever you have interchangeable algorithms — pricing rules, payment methods, sorting strategies, scheduling algorithms — Strategy lets you add new behavior without modifying existing code.
- Observer handles event-driven requirements: notifying users of stock price changes, sending order status updates, or broadcasting system alerts. It decouples the publisher from the subscriber.
- State eliminates sprawling if/elif chains by modeling each state as its own class. ATM machines, elevator systems, vending machines, and order lifecycles are all state machine problems.
- Singleton is simple but frequently tested. Database connections, configuration managers, and loggers are classic Singleton use cases. The key is knowing when Singleton is appropriate and when dependency injection is a better alternative.
- I would mention Builder as a bonus for complex object construction, and Decorator for layered behavior (middleware, permissions), but those appear less frequently in interviews.