A 30-minute skeleton for system design rounds

The system design round has a reputation for being un-preparable: open-ended, ambiguous, and graded by interviewer mood. The reputation is wrong. The round is actually a time-boxed performance with a remarkably stable shape. Interviewers do not expect a production architecture in forty-five minutes — they expect a methodical traversal of the design space, priced against a clock. A fixed skeleton turns the most open-ended hour of the interview into a series of small, predictable decisions.

You are not being asked to design the system. You are being asked to traverse it the way a senior engineer would — buy time, spend it deliberately, and surface the one hard tradeoff.

The skeleton

Here is the thirty-minute skeleton that fits the standard forty-five minute round with room to breathe. The minutes are budgets, not laws — but blowing a budget early is how designs die silently.

Window	Phase	What you are producing
0:00 – 3:00	Requirements	Functional plus non-functional targets, agreed out loud
3:00 – 7:00	Estimation	QPS, storage, bandwidth — one screen of numbers
7:00 – 11:00	API and data model	Endpoints, key entities, writes vs reads
11:00 – 21:00	High-level design	Boxes and arrows that survive the load test
21:00 – 27:00	Deep dive	One bottleneck, chosen deliberately
27:00 – 30:00	Wrap-up	Tradeoffs, next steps, failure modes

0:00 – 3:00 Requirements

The first three minutes decide the next twenty-seven. Ask exactly two questions before you draw anything. Functional: "Who uses this and what are the top three actions?" Non-functional: "What are the availability, latency, and scale targets?" Never let "design Twitter" float past you without pinning a number — 99.99% availability, p99 under 300 ms, ten million active users are answers that shape every later decision. If the interviewer says "you decide", decide, say the number out loud, and move on. A decision you announced beats a constraint you waited for.

3:00 – 7:00 Estimation

Estimation exists to give the scale decisions a spine. A tiny script, a conversation, or three lines on paper is plenty:

daily_users = 10_000_000
active_frac = 0.2
requests_per_day = 20
peak_multiplier = 3

qps = daily_users * active_frac * requests_per_day / 86_400
peak_qps = round(qps * peak_multiplier)
print(f"avg {qps:.0f} qps | peak {peak_qps} qps")

Run the same arithmetic for storage — payload bytes per event times events per day times retention in days — and you will know whether you are designing for ten nodes or a thousand. The exact numbers matter less than the conversation. Interviewers are checking that you reach for tradeoffs (sharding, caching, queues) because the numbers demand them, not because they sound knowledgeable.

7:00 – 11:00 API and data model

Write the endpoints as if an SDK team will implement them tomorrow. Concrete beats abstract:

GET  /v1/catalog/:item_id
GET  /v1/recommendations/:user_id
POST /v1/orders
POST /v1/checkout/:order_id
GET  /v1/orders/:id

Name the entities your endpoints imply — Order, PaymentAttempt, UserPreference — and state the write load versus the read load. This is the moment most candidates lose the round: they skip the data model and let the interviewer wonder how anything will be stored. A design without a data model is a mood.

11:00 – 21:00 High-level design

Draw the load-balanced tier, the service tier, and the data tier, then push the numbers through the boxes. If the read-to-write ratio is 100:1, a read replica or a cache-aside layer stops being an ornament and becomes the answer to "does this handle the load?". If single-node storage lands at four terabytes, you now have a named sharding decision. If your writes are append-heavy and time-bucketed, a queue between producers and consumers buys backpressure. The test for the diagram is cruel and simple: push peak QPS through every arrow and see which one catches fire first.

Resist the urge to draw seven microservices. A candidate who defends why three boxes win has more seniority than one who draws a conference-room diagram.

21:00 – 27:00 The deep dive

This is the only part of the round that truly separates candidates, and it is chosen, not discovered. Offer one bottleneck with both hands: "The hot path is checkout. I would shard Order by user_id, and the hard part is the idempotency key so double-taps and retries do not double-charge. Shall we walk that?" An interviewer almost always says yes — and now you are in an area you rehearsed. If they redirect, follow. The skeleton's job is done; you have shown methodical traversal, and the deep dive becomes a bonus instead of the whole grade.

27:00 – 30:00 Wrap-up

End with the three sentences interviewers remember: the biggest tradeoff you made and why, the first failure mode you would monitor in production, and the one thing you would do if given another hour. A candidate who finishes a design the way a senior finishes a project — acknowledge cost, own the risk, propose the next step — leaves a disproportionately good impression.

Where candidates actually lose time

Three failure modes account for most lost rounds. Premature diagrams: drawing before requirements pins a wrong shape and makes revising feel like backtracking. Estimate-skip: skipping the arithmetic means every later claim — "we shard it", "we cache it" — floats without evidence. The undirected deep dive: candidates with two minutes left blurt "maybe add a message queue" and hand the interviewer a messy thread instead of a decision. The skeleton is mostly an anti-failure device: it buys structure, spends it in order, and makes sure the only part that earns real points gets a deliberate runway.

Spend a session on the fundamentals with the system design basics module, rehearse under time pressure with the interview question bank, and if the whole map feels unmapped, the guided courses hand you the sequence so your thirty minutes are never spent wondering what to draw.