00. Low-Level Design — The Five-Year-Old Version¶
The city plan is done. Now we step inside each building and design the rooms.
In the HLD module we were city planners. We placed buildings, drew roads, built toll booths. We never opened a single door.
Now we open the door. We are interior designers.
Each building has rooms — separate spaces with one job each. The kitchen cooks. The bedroom sleeps. The bathroom bathes. A room that tries to do all three is a mess.
Rooms connect through hallways. The hallway is the contract. You knock, you ask for something, you get it back. You never walk into someone else's room and rummage through their drawers. That is encapsulation.
Before building anything, you draw a floor plan. The floor plan shows every room, every hallway, every door. It shows which rooms connect and which don't. Change the floor plan before pouring concrete — not after.
Inside each room you install plumbing — the pipes that carry data from one fixture to another. Data flows in, gets transformed, flows out. Bad plumbing means leaks. Leaks mean bugs.
Finally, the building needs wiring — the electrical system that triggers actions. When someone flips a light switch, the light turns on. When the smoke detector senses smoke, the alarm fires. That is event handling and state management. The wiring is the behavioral logic.
LLD is what happens inside the boxes from HLD. You take one service — say the Tweet Service — and design its classes, interfaces, data access, state machines, and error handling. The floor plan is a class diagram. The rooms are classes. The hallways are interfaces. The plumbing is data flow. The wiring is behavior.
Why does this matter? Because two systems with identical HLD can have wildly different code quality. One is maintainable, testable, extendable. The other is a tangled mess. The difference is LLD.
A good interior design survives change. The owner wants to convert a bedroom into an office. With good hallways and separate rooms, you move furniture and repaint. With bad design — load-bearing walls everywhere, shared plumbing between rooms — converting one room means demolishing three.
Software is the same. Good LLD means adding a feature touches one class. Bad LLD means adding a feature touches twenty.
The placeholders you will see called back¶
| Placeholder | Meaning |
|---|---|
| floor plan | the class diagram or schema design — rooms and connections before any code |
| room | a class or module with a single responsibility |
| hallway | the interface or contract between classes — how rooms communicate |
| plumbing | the internal data flow — how data moves through the system |
| wiring | the behavioral logic — state machines, event handlers, triggers |
Top resources¶
- Head First Design Patterns — the most accessible design patterns book; visual, practical, memorable
- Clean Code by Robert C. Martin — foundational principles for writing maintainable code at the class level
- Refactoring Guru — Design Patterns — free, visual catalog of all GoF patterns with real-world examples
- System Design Interview LLD playlist (YouTube) — walkthrough videos for parking lot, elevator, and other classic LLD problems
- Martin Fowler — Patterns of Enterprise Application Architecture — data access patterns, domain models, and service layer patterns
What's coming¶
- 01-from-hld-box-to-classes.md — turning one HLD service box into classes and interfaces
- 02-solid-principles.md — the five rules that keep rooms clean and hallways stable
- 03-creational-patterns.md — factory, builder, singleton — how to create objects without chaos
- 04-structural-patterns.md — adapter, decorator, proxy, facade — connecting rooms without remodeling
- 05-behavioral-patterns.md — strategy, observer, command, state — the wiring that triggers actions
- 06-class-and-schema-design.md — drawing the floor plan: UML, relationships, cardinality
- 07-api-contract-design.md — OpenAPI, protobuf, schema validation at the code level
- 08-state-machines-and-workflows.md — modeling business logic as explicit state transitions
- 09-error-handling-and-resilience.md — exceptions, retries, and graceful degradation inside the service
- 10-concurrency-patterns.md — thread pools, locks, async/await, and race conditions
- 11-data-access-patterns.md — repository, DAO, unit of work, and ORM tradeoffs
- 12-design-patterns-for-ai.md — strategy for model swap, pipeline for preprocessing, observer for monitoring
- 13-ai-component-lld.md — prompt management, model serving internals, feature transformation
- 14-honest-admission.md — what we don't fully understand about designing software internals
Bridge. The floor plan is blank. First step: take one HLD box and figure out what rooms it needs. → 01-from-hld-box-to-classes.md