How to approach any new LLD problem from scratch.
In DSA you go Brute → Better → Optimal by removing repeated work. In LLD you go Vague prompt → Naive MVP → Pain point → Clean design by finding what changes and hiding it behind the right boundary.
The 5-step thinking process (use this in every interview)
Clarify & scope the 45-minute target
Interview prompts are vague on purpose ("Design BookMyShow", "Design an ATM"). Never jump straight into classes. Ask a few focused questions to fix the boundary:
- •
Core happy path: which 2–3 methods will the caller use 90% of the time?
- •
Failure & edge cases: invalid transitions, not enough stock, partial failure?
- •
Concurrency: single-threaded in memory, or do threads race for the same thing (seat locking, rate limiting)?
- •
Out of scope: you design in-memory classes and interfaces — not SQL schemas, REST controllers, or UI.
Extract the nouns — and reject the false classes
Underline every noun in the requirements and put each one in a bucket. Beginners fail by turning every noun into a heavy class:
- •
Value struct: plain data with no rules (
Ticket,Money,Coordinates,LogMessage). - •
Stateful class / manager: owns invariants and transitions (
Order,SeatLockManager,AtmMachine). - •
Interface: anything with more than one implementation (
PricingStrategy,PaymentGateway,EvictionPolicy). - •
Not a class: trap nouns like
Price,Timestamp,Statusbecome fields,enum classvalues or return types.
Sketch the naive MVP and ask "what breaks tomorrow?"
Picture the simplest single-class version first, then stress-test it against change. A pattern is only ever the cure for a concrete smell:
- •
Long
if/elseon which algorithm? Every new rule edits the core class (breaks Open-Closed). - •
Boolean flags (
isPaid_,isCancelled_)? Illegal combinations compile and cause bugs. - •
One method calls 4 subsystems directly? Impossible to test without real gateways and databases.
Map only the real hotspots to patterns
Add an interface or pattern only where something genuinely varies. In most interviews 2–3 patterns working together is the sweet spot:
- •
Pluggable rule or calculation → Strategy (A1) injected through the constructor.
- •
Strict lifecycle with guarded transitions → State (A4).
- •
One event, many independent reactions → Observer (A3).
- •
Multi-step workflow → Facade (A9), or Command (B4) when you need undo / rollback.
Write modern C++23 — ownership, invariants, locks
Turn the UML boxes into clean C++23 that compiles and proves its invariants in `main()`:
- •
Ownership (F5):
std::unique_ptr<Interface>for owned polymorphic parts, value members by default, references for borrowing. No rawnew/delete. - •
Errors (F7): return
std::expected<T, Error>orstd::optional<T>for normal rejections, not-1or exceptions. - •
Concurrency: guard shared state with
std::mutex+std::scoped_lock, and never hold a lock across slow I/O such as a payment call.
Pain point → design pattern decision tree
Don't memorise patterns one by one. Start on the left with the pain hurting your naive code, follow the branch that matches, and open the chapter that fixes it.