2. The Framework: A 45–60 Minute Design, Step by Step

Use one framework every time so your energy goes into the problem and not into deciding what to do next. Timings are for a 45-minute round; scale them up proportionally for 60.

 ┌──────────────────────────────────────────────────────────────────────────┐
 │ 0. Business goal & users          (2-3 min)  "Why does this exist?"      │
 │ 1. Functional requirements        (3 min)    3-5 core use cases, scoped  │
 │ 2. Non-functional requirements    (3 min)    scale, latency, availability │
 │                                              consistency, durability, cost│
 │ 3. Estimates                      (3-4 min)  QPS, storage, bandwidth      │
 │ 4. API & data model               (5 min)    contracts + entities + keys  │
 │ 5. High-level design              (8-10 min) end-to-end, every use case   │
 │ 6. Deep dives                     (12-15 min) the 2-3 hardest parts       │
 │ 7. Failure, scale, evolution      (5 min)    what breaks, 10x, cost, org  │
 │ 8. Wrap-up                        (1-2 min)  recap trade-offs & next steps│
 └──────────────────────────────────────────────────────────────────────────┘

Step 0 — Business goal & users

Ask before anything else:

Who are the users (consumers, enterprises, internal teams, other machines)?
What outcome does the business want? (Revenue, engagement, cost reduction, compliance, a platform other teams build on.)
What does failure cost? (Lost revenue per minute, regulatory penalties, trust.)
Is this greenfield or replacing something? Candidates at any senior level who ask this stand out, because most real work is migration. (§27 later shows how to turn these answers into numbers and architecture decisions.)

Step 1 — Functional requirements

List them, then explicitly cut scope: "I'll focus on posting, the home timeline, and follow. I'll treat search, ads, and DMs as out of scope unless you want them." Writing the cut list down is a strong signal.

Step 2 — Non-functional requirements (NFRs)

Never say "highly available and scalable" without a number. Use this checklist:

NFR	Question to ask	Example answer
Scale	DAU/MAU, peak vs average, growth rate	200M DAU, 3× peak, 2× per year
Latency	Which operations, which percentile	Timeline read p99 < 200 ms
Availability	Which paths, how many nines	Reads 99.99%, posting 99.9%
Consistency	What can be stale, for how long	Timeline eventually consistent (≤5 s); follows read-your-writes
Durability	Can we lose data?	Posts: never. View counts: approximate OK
Cost	Budget or unit cost target	< $0.50 per 1k DAU per month
Compliance	PII, residency, retention	GDPR deletion within 30 days, EU data in EU
Read/write ratio	Shapes storage & cache	100:1 read-heavy

Step 3 — Estimates

Only estimate what changes a decision (§3). "Write QPS is 6k, so a single Postgres primary works; read QPS is 600k, so we need a cache tier" is useful. Spending ten minutes on bytes-per-row arithmetic that changes nothing is not.

Step 4 — API & data model

Write 3–6 API signatures and the core entities, with their primary key and partition key. The partition key is the most important line on the board, because it decides scalability, hotspots, and which queries are cheap.

Step 5 — High-level design

Draw the path of every functional requirement end to end. Trace one write and one read through the diagram out loud. (§63 shows how to draw it fast and legibly on a whiteboard, on paper, or on a virtual canvas.)

Step 6 — Deep dives

Pick the parts where the system is hard, or let the interviewer pick. Typical deep dives: the hot path's data store, fan-out, consistency of a critical counter, the concurrency control on a contended resource, the cache invalidation strategy.

Step 7 — Failure, scale, evolution

Walk through: "What if X dies? What if traffic is 10×? What gets expensive first? What do we build in v1 vs v2? Who owns what?"

Step 8 — Wrap-up

Thirty seconds: "Recap: we optimized for X, accepted Y as the trade-off, and the biggest risk is Z, which I'd mitigate by W."