Cruxly › Low-level design interview preparation

Low-level design interview preparation

Low-level design interviews ask you to turn a short prompt into classes, responsibilities and interactions that stay easy to change. These lessons cover the method, the principles behind good structure, the patterns that come up, and worked exercises.

Running the LLD Interview

Turning a vague prompt into classes, interfaces and invariants — under 45 minutes, out loud.

• Clarifying an LLD Promptturning four words into a finite model
• From Nouns to a Defensible Modelentities, ownership, invariants — in that order
• Absorbing the Follow-Upthe requirement they add at minute 35

Principles & Patterns

SOLID and the handful of patterns that actually recur in LLD interviews — each one motivated by a smell, not memorised by name.

• Single Responsibilityone class, one reason to change
• Open/Closedextend without editing
• Liskov Substitutiona subtype must not surprise the caller
• Interface Segregationno client should depend on methods it doesn't use
• Dependency Inversiondepend on abstractions, not on concrete details
• The Patterns That Actually RecurStrategy, Factory, Observer, Decorator, Adapter — motivated, not memorised

More Design Patterns

Builder, Singleton, Facade, Proxy, Chain of Responsibility — the next five, with full code and the case against each one.

• Builderconstruction with many optional, interdependent parameters
• Singletonexactly one instance, reachable from everywhere — and why that is usually a trap
• Facadehiding a wide subsystem behind the slice callers actually need
• Proxyintercepting access without the caller knowing
• Chain of Responsibilityexactly one handler, chosen by trying candidates in order

LLD Exercises

Components worked end to end — each one corners you into a different hard decision.

• Rate Limiteralgorithm choice, then the check-then-act race
• LRU Cachetwo structures in lockstep, every operation O(1)
• Elevator Banka scheduler with no right answer — only defensible policies
• Expense Splittingmoney that cannot drift, and a settlement algorithm
• Chess / Game Boardper-piece rules without an inheritance explosion
• Logging Frameworkthe calling thread must never wait on a disk
• Vending Machinea state machine that must never dispense without payment, and never eat money
• Movie Ticket Bookingtwo users cannot hold the same seat, and a hold must expire on its own
• Notification System (LLD)one send() call, several channels, and a retry policy that must not duplicate
• In-Memory File Systema file and a directory are the same interface, and that single decision buys everything else
• ATM Machinea transaction is a sequence of hardware side effects, and one of them can fail after the money is already committed
• Text Editor Undo/Redoevery edit must know how to reverse itself, and a new edit must destroy the wrong future
• Meeting Room Schedulerbooking a room is an interval-overlap problem wearing a calendar's clothes
• Pub/Sub Systempublishers and subscribers must not know about each other, and slow subscribers must not block fast ones
• Leaderboardthe update is O(log n), the read is O(1), and rank is a derived value, not stored state
• Search Autocomplete (LLD)a trie gets you the matches; ranking the top few is the actual exercise
• Hit Countercounting hits in the last N seconds without storing every hit forever
• LFU Cacheeviction by frequency, not recency — and both O(1) is a different structure than LRU's