“Design Twitter” is not a question about Twitter. It’s a question about whether you can impose order on ambiguity while someone watches you think. Candidates who treat it as a trivia test — name-dropping Kafka, Cassandra, and Redis in the first two minutes — fail predictably. Candidates who treat it as a structure problem pass predictably.
Here’s the structure. Four layers, in order, every time. It works for URL shorteners and it works for distributed payment systems, because the layers are about how you think, not what you’re designing.
- Four layers, in order, every time: requirements, API, data model, scale.
- Spend the first five minutes interrogating requirements — it signals judgment and prevents solving the wrong problem.
- Justify every technology from the access pattern, never from hype.
- Close by naming your own trade-offs; stated weaknesses read as senior.
“Senior engineers don’t know more technologies. They ask better questions in the first five minutes.”
Layer 1: Requirements (first 5 minutes)
Never start designing. Start interrogating. Functional requirements first — what does it do, for whom, at minimum? Then non-functional: scale, read/write ratio, latency expectations, consistency needs.
- “Are we designing for 1,000 users or 100 million?”
- “Is this read-heavy or write-heavy?”
- “Does a stale answer for 30 seconds break anything?”
This layer does three jobs at once: it buys you thinking time, it prevents you from solving the wrong problem, and it signals judgment — the thing the interviewer is actually scoring.
Layer 2: API and interface
Before storage, before diagrams, define the contract. Two or three endpoints, written out loud: POST /shorten, GET /{id}. This forces the design to be concrete, exposes assumptions early (“wait — do users need custom aliases?”), and shows product thinking, which is what separates senior from junior in these rounds.
Layer 3: Data model and storage
Now, and only now, choose technologies — and justify each one from the access pattern, not from hype. “Reads dominate 100:1, so a key-value store fits; the schema is three columns; here’s why I’m not reaching for a graph database” is a senior answer. The technology is never the point. The mapping from requirement to choice is the point.
Read by candidates who stopped freezing.
Interview Clozo’s system-design panes generate this four-layer structure live, per question. Start Free Trial.
Start Free Trial →By continuing, you agree to our Terms of Service and Refund Policy.
Layer 4: Scale and trade-offs
Only after the simple version exists do you break it. Add load one layer at a time and let each bottleneck earn its solution: cache when reads hurt, shard when a single node can’t hold the data, queue when writes burst. Then close with the part most candidates skip — name the trade-offs you made, unprompted:
- Consistency vs availability — and which you chose, why
- Latency vs durability
- Cost vs complexity — “this adds an ops burden I’d only accept above 10M DAU”
A design with stated trade-offs reads as senior. A design presented as flawless reads as junior. Interviewers trust engineers who know where their own system breaks.
The 60-second version
- Requirements: interrogate before you design. Scale, ratios, consistency.
- API: write the contract out loud. Make it concrete.
- Data: map each access pattern to a storage choice, with a reason.
- Scale: break the simple design one bottleneck at a time, then name your trade-offs.
Run this sequence on ten practice questions — it covers the design rounds in software engineering and data science loops alike — and it stops being a framework and starts being reflex — which is the entire goal, because in the real interview you won’t have bandwidth for anything that isn’t reflex.
