Low-Level Design (LLD)
There are two design interviews, and they’re often confused. Everything else in this chapter is high-level design (HLD) — boxes, servers, databases, scale. Low-level design zooms all the way in: “design the classes for a parking lot / elevator / vending machine / deck of cards.” No QPS, no sharding — just clean, extensible object-oriented code.
What LLD interviews actually grade
Not whether your code runs — whether your class design is clean, extensible, and shows you know OOP. The signals they look for:
- The right objects — did you find the real entities and give each a single, clear responsibility?
- Good relationships — sensible use of inheritance vs composition, interfaces over concrete types.
- Extensibility — can you add a new vehicle type / payment method without rewriting everything? (Open/Closed.)
- Appropriate patterns — used where they help, not bolted on for show.
The LLD interview script
1. Clarify requirements & scope
Same as HLD: pin down the use cases. “A parking lot has multiple levels, multiple spot sizes, issues a ticket on entry, charges on exit.” List the core behaviors out loud.
2. Identify the core objects (nouns)
Scan the requirements for nouns — they’re usually your classes. Parking lot → ParkingLot, Level, ParkingSpot, Vehicle, Ticket, Payment. Scan for verbs — they’re usually your methods (parkVehicle, issueTicket, processPayment).
3. Define relationships
Who has whom (composition), who is a kind of whom (inheritance)? A ParkingLot has Levels; a Car is a Vehicle. Prefer composition; use inheritance only for genuine “is-a”.
4. Sketch the classes — fields + key methods
Write the class skeletons: fields and method signatures. You don’t need full bodies — the structure is what’s graded.
5. Apply patterns & SOLID where they earn their keep
Reach for a pattern only when it solves a real problem in the design (a Factory to create vehicles, a Strategy for pricing). Name the principle you’re honoring.
6. Walk a use case through the objects
Narrate one flow end-to-end: “A car enters → ParkingLot.parkVehicle(car) finds a free ParkingSpot, creates a Ticket, marks the spot occupied…” This proves the design actually works.
SOLID — the five principles, in one line each
The vocabulary interviewers listen for. Drop the name when you make the corresponding choice.
| Principle | One-line meaning | |
|---|---|---|
| S | Single Responsibility | a class should have one reason to change |
| O | Open/Closed | open for extension, closed for modification (add code, don’t edit it) |
| L | Liskov Substitution | a subclass must be usable anywhere its parent is, without surprises |
| I | Interface Segregation | many small interfaces beat one fat one — don’t force unused methods |
| D | Dependency Inversion | depend on abstractions (interfaces), not concrete classes |
Open/Closed is the one that wins LLD interviews. When asked “how would you add motorcycles / electric-charging spots / a new payment method?”, a design that lets you add a new class without touching existing code is the whole point. If your answer requires editing a giant if/else on vehicle type, you’ve failed Open/Closed — refactor to polymorphism or a strategy.
The patterns worth knowing (and when they show up)
You don’t need all 23 Gang-of-Four patterns. These few cover the vast majority of LLD prompts:
| Pattern | Solves | Shows up in |
|---|---|---|
| Strategy | swap an algorithm at runtime | pricing rules, payment methods, sorting policy |
| Factory | create objects without hard-coding the class | ”make the right Vehicle/Notification subtype” |
| Singleton | exactly one shared instance | a single ParkingLot / config / logger (use sparingly) |
| Observer | notify many listeners on a change | event systems, pub/sub, “spot freed → alert waiters” |
| Decorator | add behavior without subclassing | add-ons, toppings, middleware |
| State | behavior changes with internal state | vending machine, order lifecycle, traffic light |
A worked mini-example: parking lot
The most-asked LLD question. The class breakdown:
A skeleton — note it’s structure, not full implementation:
Don’t over-engineer. The fastest way to fail LLD is to cram in five patterns nobody asked for. Start with clean classes and single responsibilities; introduce a pattern only when the interviewer’s follow-up (“now support a new payment type”) makes the need obvious. A simple, extensible design beats a clever, pattern-stuffed one.
Quick check
Next: Basic Questions — concept checks across both the high-level and low-level material, then the practice set.