🎉 All 30 days are live — the full DSA-30 course, from Big-O to System Design. See the roadmap →
Day 28 - System Design 101Low-Level Design (LLD)

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.

Two different zoom levels — know which one you're being asked
zoom inHLDservices, DBs, scaleLLDclasses, methods, patterns
HLD: 'how do the machines fit together?' LLD: 'how do the classes fit together inside one service?' If the prompt is 'design a parking lot' with no mention of scale, it's almost always LLD.

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.

PrincipleOne-line meaning
SSingle Responsibilitya class should have one reason to change
OOpen/Closedopen for extension, closed for modification (add code, don’t edit it)
LLiskov Substitutiona subclass must be usable anywhere its parent is, without surprises
IInterface Segregationmany small interfaces beat one fat one — don’t force unused methods
DDependency Inversiondepend 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:

PatternSolvesShows up in
Strategyswap an algorithm at runtimepricing rules, payment methods, sorting policy
Factorycreate objects without hard-coding the class”make the right Vehicle/Notification subtype”
Singletonexactly one shared instancea single ParkingLot / config / logger (use sparingly)
Observernotify many listeners on a changeevent systems, pub/sub, “spot freed → alert waiters”
Decoratoradd behavior without subclassingadd-ons, toppings, middleware
Statebehavior changes with internal statevending machine, order lifecycle, traffic light

A worked mini-example: parking lot

The most-asked LLD question. The class breakdown:

Parking lot — composition (has-a) and inheritance (is-a)
has manyhas manyissuesforis-ais-ais-ausesParkingLotSingletonLevelParkingSpotsize, isFreeTicketentryTimeVehicleabstractCarMotorcycleTruckPaymentStrategyinterface
ParkingLot (Singleton) has-many Levels, each has-many ParkingSpots. Vehicle is an abstract base; Car/Motorcycle/Truck extend it (add a new type without touching existing code — Open/Closed). PaymentStrategy is an interface so card/cash/UPI swap freely.

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

An interviewer asks you to add 'electric charging spots' to your parking-lot design. Your current code has a switch statement on spot type scattered in three methods. What does this reveal?
When does it make sense to introduce the Strategy pattern in an LLD interview?
What's the core difference between a high-level design (HLD) and a low-level design (LLD) interview?

Next: Basic Questions — concept checks across both the high-level and low-level material, then the practice set.