Approaching a System Design Interview: HLD, LLD & the RESHADED Framework
A repeatable structure for answering any open-ended "design X" prompt, from a parking-lot pricing engine to a global chat app.
Beginner
TopNotchNote
Notes that matter
high-level design vs. low-level design
System design questions get asked at two different altitudes, and it's worth being explicit about which one is on the table before diving in.
| High-Level Design (HLD) | Low-Level Design (LLD) | |
|---|---|---|
| Focus | The overall architecture: which services exist, how they talk, which databases back them. | The internals of one subsystem: classes, interfaces, algorithms. |
| Example question | "Design a ride-hailing app." | "Design the class structure for the fare-pricing engine." |
| Typical output | A diagram of services, data stores, and the request flow between them. | Interfaces, class diagrams, and sometimes real code. |
Neither is "more advanced" than the other — they're answering different questions. A strong HLD answer that never mentions a single class is completely appropriate for "design Instagram"; a strong LLD answer that never mentions horizontal scaling is completely appropriate for "design a parking-lot pricing engine." Confusing the two is one of the most common ways candidates lose time in an interview: going deep on class diagrams when the interviewer wanted service boundaries, or vice versa.
locking down requirements before designing anything
Every credible approach to a design problem starts the same way: don't propose an architecture until the scope is clear. See Functional vs. Non-Functional Requirements for the mechanics — the point here is sequencing. Skipping this step and jumping straight to "we'll use microservices with Kafka" is the single most common way designs go sideways, because the proposal ends up solving a problem nobody actually stated.
A second, easy-to-miss expectation: the design should be reasonably future-proof. If a notification service is asked to send email and SMS today, a design that hardcodes "email" throughout the codebase instead of an abstracted "notification channel" will need a rewrite the day push notifications are added. Future-proofing doesn't mean over-engineering for hypothetical requirements — it means not painting the design into a corner for entirely foreseeable ones.
the RESHADED framework
A useful checklist for structuring an answer to any "design X" prompt, whether in an interview or a real architecture doc, is the mnemonic RESHADED. It doesn't have to be followed in lockstep, but skipping a step usually means that step gets asked about later anyway.
| Letter | Step | What it covers |
|---|---|---|
| R | Requirements | Functional and non-functional requirements — what the service does and how well it must do it. |
| E | Estimation | Back-of-the-envelope numbers for servers, storage, and bandwidth at the stated scale. |
| S | Storage schema | The data model: what tables/collections exist and what fields they hold (optional — not every problem needs this level of detail). |
| H | High-level design | The main components and how they connect, driven by the functional requirements. |
| A | API design | The interfaces client and internal callers actually use — a direct translation of the functional requirements. |
| D | Detailed design | Where the high-level design's limitations get addressed — the interesting trade-offs live here. |
| E | Evaluation | Explicitly checking the design against the non-functional requirements, and naming the trade-offs made. |
| D | Distinctive component | The one part of this specific problem that isn't boilerplate — fraud detection for a payments app, concurrency control for a collaborative doc editor. |
how an interviewer is actually grading this
There's rarely a single "correct" architecture for an open-ended prompt like "design Twitter." What's actually being evaluated is whether a candidate can reason clearly about trade-offs as requirements evolve mid-conversation — which is exactly what happens on a real team when a PM adds a requirement after the design doc is already written.
Two habits matter more than knowing the "right" answer: narrating the thought process out loud instead of designing silently, and stating a design's limitations proactively ("this doesn't handle a regional outage, and here's what it would take to fix that") rather than waiting to be asked. Silence reads as uncertainty even when the underlying design is sound.