Cheat sheet: Low-level design
Every module and problem on one page: its memory hook and the points worth saying out loud. Print it (Ctrl/⌘ P) and re-read it before a practice session; open the page behind any card when something doesn't come back to you. Built automatically from the pages, so it always matches them.
Level 1 · Foundations
How low-level design interviews work
“Clarify, nouns, classes, flow, code, extend”
Six steps in 45 minutes, in that order, with most of the time on classes and code.
- Avoid
- Coding immediately
- A class for every noun
- One giant manager class
OOP essentials
“Hide the data, show the behaviour, hold rather than be”
Encapsulate state, program to what objects do, and prefer composition to inheritance.
- Avoid
- Public fields with setters for everything
- Inheriting to reuse code
- if/else on types
SOLID in practice
“One job, add don't edit, keep promises, small interfaces, plug in”
Five principles, one phrase each.
- Avoid
- Abstracting everything
- God classes
- Subclasses that refuse parent methods
Single responsibility in depth
“One class, one team asking”
A class has one responsibility when only one group can ask for it to change.
- Avoid
- Counting methods instead of askers
- Splitting by step
- Classes called Helper, Utils or Manager
Open/closed in depth
“Add a plug, don't rewire the wall”
New behaviour arrives as new code at an extension point; tested code stays as it is.
- Avoid
- A switch that grows with every variant
- An interface for everything
- Extension by subclassing a big base class
Liskov substitution in depth
“Keep the parent's promises”
A subtype may accept more and guarantee more, never demand more or deliver less.
- Avoid
- Overrides that throw "not supported"
- instanceof checks in callers
- Silent changes
Interface segregation in depth
“Each caller gets its own key card”
Interfaces are shaped by what each caller needs, not by everything the object can do.
- Avoid
- One interface for the whole object
- One interface per method
- Passing the concrete class anyway
Dependency inversion in depth
“Policy owns the plug”
High-level code defines the interfaces it needs; details implement them and are plugged in from outside.
- Avoid
- new inside business logic
- Interfaces shaped like the vendor's SDK
- A service locator everywhere
Design patterns you'll actually use
“Swap, change, notify, create, wrap”
Strategy swaps an algorithm, state changes behaviour with state, observer notifies, factory creates, decorator wraps.
- Avoid
- Pattern first, problem second
- Singleton for convenience
- Confusing strategy and state
Class and sequence diagrams
“The map shows what is; the directions show one trip”
Class diagrams show structure; sequence diagrams show one use case over time.
- Avoid
- Every field and getter
- Composition vs association confused
- No interfaces shown
Concurrency and thread safety
“Check and act under one lock; lock in one order”
Guard every check-then-act with a single lock, and when you need two locks, always take them in the same order.
- Avoid
- Locking only the write
- Two locks in different orders
- Holding a lock during slow I/O
Level 2 · Warm-up problems
LRU cache
“Map to find, list to order”
The dictionary finds the node instantly; the linked list keeps the order and lets you unlink it instantly.
- Patterns
- Composition
- Sentinel nodes
- Decorator (follow-up)
- Avoid
- Using a list and scanning it
- Forgetting the key in the node
- Not refreshing on get
Rate limiter
“Tokens drip in, requests take them out”
A bucket refills at a steady rate up to its capacity; each request needs one token or is rejected.
- Patterns
- Strategy
- Dependency injection
- Lazy refill
- Avoid
- Calling the system clock inside allow()
- A timer per client to refill
- Fixed windows without saying so
Logging framework
“Filter early, fan out, format at the edge”
The logger drops what's below its level before doing any work; each appender decides and formats for itself.
- Patterns
- Strategy
- Template method
- Observer-like fan-out
- Avoid
- Formatting before filtering
- Hard-coding destinations
- One threshold for everything
Tic-tac-toe
“Plus one, minus one, look for n”
Each move adds its player's value to its lines; a line summing to ±n is a win.
- Patterns
- Single responsibility
- Encapsulation
- Strategy (follow-up)
- Avoid
- Scanning the board after every move
- Putting turn logic in the board
- Checking for a draw before a win
Snake and ladder
“A jump is a jump”
Snakes and ladders are one map from square to square; the dice is an interface so tests can script it.
- Patterns
- Strategy / dependency injection
- Data over classes
- Queue
- Avoid
- Separate Snake and Ladder classes
- Random numbers inside Game
- Index arithmetic for turns
Level 3 · Classic systems
Parking lot
“Find, hold, ticket; then free and price”
Entry finds the smallest spot that fits and records it on a ticket; exit frees the spot and asks the fee strategy what to charge.
- Patterns
- Strategy
- Enums with data
- Single lock around check-and-assign
- Avoid
- A Car class that extends Vehicle for every type
- Pricing inside ParkingLot
- Check-then-assign without a lock
Vending machine
“The state answers, the machine delegates”
The machine forwards every action to its current state object; states decide the answer and the next state.
- Patterns
- State
- Validation at the edge
- Integer cents
- Avoid
- A big switch on state in every method
- Changing state before dispensing
- Floats for money
ATM
“Plan the notes, debit, then pay”
Ask the chain whether the amount can be made, take the money from the account, and only then count out the notes.
- Patterns
- Chain of responsibility
- Plan, then commit
- State (as an enum)
- Avoid
- Dispensing before debiting
- Changing note counts during planning
- No state checks
Library management
“Lend copies, queue for titles”
Status lives on each copy; the waitlist is per title, and a returned copy is held for the head of the queue.
- Patterns
- Title vs instance
- State as an enum
- Strategy
- Avoid
- One Book class with an available flag
- Putting a returned reserved book back on the shelf
- Fines computed in five places
Elevator system
“Pick a car, then sweep”
The scheduler picks the car; each car keeps going while it has stops ahead, then turns around.
- Patterns
- Strategy
- Simulation clock
- LOOK algorithm
- Avoid
- One giant if-statement for scheduling
- Serving stops in call order (FIFO)
- Real time and threads per car
Level 4 · Bigger designs
Expense sharing (Splitwise)
“Cents in, nets out, greedy settle”
Split in integer cents so shares add up exactly, keep one net balance per person, and settle biggest debtor against biggest creditor.
- Patterns
- Strategy
- Net balances
- Greedy settlement
- Avoid
- Floats for money
- A switch on split type in the ledger
- Not validating exact or percent splits
Movie ticket booking
“Hold under the lock, expire by the clock”
Check and mark all seats inside the show's lock; a hold that's past its time simply stops counting.
- Patterns
- Lock per show
- Lazy expiry
- All-or-nothing
- Avoid
- Checking availability, then booking in a separate step
- A cleanup job as the only way holds expire
- Holding the lock while calling payment
Hotel reservation
“a.in < b.out and b.in < a.out”
Two half-open stays overlap only if each starts before the other ends.
- Patterns
- Half-open ranges
- Search and book under one lock
- Enum with data
- Avoid
- Closed ranges [in, out]
- Checking overlap with only one condition
- Search and book in separate steps without a lock
Pub-sub message queue
“Keep the log, move the bookmark”
Messages stay in the topic; each consumer group just moves its own bookmark forward when it has finished.
- Patterns
- Append-only log
- Offsets per consumer group
- Poll, then commit
- Avoid
- Deleting messages when one consumer reads them
- Committing before processing
- One offset for everyone
File search (Unix find)
“Small filters, combined”
Each filter answers one question; and, or and not build any query from them, so the walker never changes.
- Patterns
- Composite
- Specification
- Iterative traversal
- Avoid
- A search method per combination
- Recursion on very deep trees
- Mixing traversal and filtering logic