LLD Problem Roadmap¶
Work each exercise with the solution covered — design your own classes first, then compare. Every exercise applies the 9-step approach: requirements → entities → classes → relationships → abstractions → patterns → core code → edge cases → concurrency.
Read OOP Fundamentals, SOLID, Design Patterns, and Concurrency Basics first — these exercises assume that vocabulary rather than re-teaching it each time.
Beginner¶
Entity modeling, basic composition, simple state — no concurrency pressure yet.
| Problem | Status | Core skill |
|---|---|---|
| Parking Lot | Complete | Composition, Strategy (pricing), spot allocation |
| Tic Tac Toe | Complete | Simple state machine, win-condition checking |
| Library Management | Complete | Multi-entity relationships (Book, Member, Loan), due-date rules |
| Splitwise | Complete | Graph simplification (debt netting), Strategy (split types) |
Intermediate¶
State machines, multi-entity coordination, strategy selection under real constraints.
| Problem | Status | Core skill |
|---|---|---|
| Elevator System | Complete | State machine, Strategy (scheduling algorithm), request coordination |
| ATM | Complete | State machine (card inserted → PIN → transaction), State pattern |
| Vending Machine | Complete | State pattern, inventory + payment coordination |
| Chess | Complete | Polymorphism (piece movement rules), move validation, Command pattern (undo) |
| Car Rental | Complete | Inventory + reservation overlap, pricing strategy |
Advanced¶
Data-structure design under real constraints, concurrency, extensibility at scale.
| Problem | Status | Core skill |
|---|---|---|
| LRU Cache | Complete | Data structure design (hash map + doubly linked list), O(1) constraint, thread safety |
| Rate Limiter (LLD) | Complete | Algorithm choice (token bucket vs. sliding window) at the class level — pairs with Rate Limiting for the distributed-systems version |
| Logger | Complete | Singleton (carefully — see the trap below), Strategy (sinks), async writes |
| Notification System (LLD) | Complete | Observer, Strategy (channels) — pairs with Notification System for the distributed version |
| Pub/Sub | Complete | Observer at scale, thread-safe subscriber management |
| Task Scheduler | Complete | Priority queue, Strategy (scheduling policy), concurrency (worker pool) |
All fifteen exercises are written to the same bar: 9-step structure, worked solution, edge cases, concurrency, and three-tier interview questions.
The Singleton trap
Logger is listed here because it's the canonical Singleton example — and also the canonical example of Singleton done badly: a global mutable object that's hard to test (can't inject a fake), hides a dependency (any class can silently call Logger.instance()), and gets shared state bugs the moment logging becomes concurrent. When you reach it, the interesting design question isn't "implement a Singleton," it's "what does dependency-injecting a Logger instance buy you over a global, and is there ever a case a true singleton is actually correct" (there is — genuinely global config, unique resource handles — but state it as a deliberate trade-off, not a default).
How to Use These Pages¶
Each exercise follows the same structure so you can compare your own attempt against it section by section:
- Problem statement — a real prompt, not a toy simplification
- Requirements — functional scope, explicitly out-of-scope items
- Entities — the nouns, before any class is written
- Class design — a
classDiagram(Mermaid) plus the actual field/method signatures - Patterns applied — named only where a real variation point earns them
- Core code — the 2-3 operations that matter, fully implemented
- Edge cases — the ones interviewers actually probe
- Concurrency — what breaks with two threads, and the fix
- Extensibility — what changes, and what doesn't, when a new requirement arrives
Next: Parking Lot