The 45-Minute Framework

The budget

For a 45-minute round, aim for roughly:

Say the budget out loud at the start: "I'll take about five minutes on requirements, then sketch the high level, then go deep wherever you'd like." This does two things — it shows you have a process, and it gives the interviewer a natural place to redirect you.

Stage 1 — Scope & requirements (5 min)

The most-skipped and highest-leverage stage. You are trying to shrink an impossibly broad prompt into something buildable in forty minutes.

Functional requirements. What must it do? List 3–5 things and explicitly park the rest: "I'll cover posting and reading the feed. I'll assume ranking is out of scope unless you'd like it in." Parking things is not dodging — it's scoping, and it reads as senior.

Non-functional requirements. This is where the design actually gets decided:

• Scale — users, requests, data volume, growth.
• Read/write ratio — a 100:1 read-heavy system and a write-heavy one share no architecture.
• Latency target, and at which percentile.
• Consistency — per operation. See the consistency spectrum.
• Availability target — and what it costs the business to be down.

Write the requirements somewhere visible and refer back to them. When you later say "because we agreed reads dominate 100:1, I'll denormalise here", you are demonstrating that your design follows from the requirements rather than from memory.

Stage 2 — Estimation (5 min)

Covered mechanically in latency & estimation. What matters here is the purpose: you are not doing arithmetic to prove you can, you are looking for the number that changes the design.

Do it out loud, round aggressively, and then say what the number means:

"50,000 writes a second means this can't be a single Postgres primary — that pushes us to partition by driver ID."

"The whole hot set is 13 MB, so it fits in memory on one machine and most of this complexity disappears."

An estimate that doesn't change anything was the wrong estimate. If your numbers come out small, say so and simplify — proposing a distributed system for a workload that fits on one box is a real and common failure.

Stage 3 — API & data model (6 min)

Concrete beats abstract. Write actual signatures:

POST /rides            {rider_id, pickup, dropoff, idempotency_key} → {ride_id, status}
GET  /rides/{id}                                                    → {ride_id, driver, eta}

Then the data model: entities, key fields, and — critically — the partition key and the indexes the access patterns require. Choosing the partition key is where most of the design lives, and it's the thing weak answers leave implicit.

Mention idempotency keys on any mutating endpoint. It takes four seconds and signals a lot.

Stage 4 — High-level design (12 min)

Draw the boxes. Client → load balancer → service → datastore, plus caches, queues, and whatever the problem needs.

Two habits that separate good from average:

1. Trace one request end to end, out loud, before adding anything else. "A rider requests a ride: hits the API gateway, the matching service reads nearby drivers from the geo index…" A design you can narrate is a design that works.
2. Get to a complete-but-simple system first, then improve it. A working monolith you then scale beats a half-drawn microservice diagram. You can always add; you can't finish what you never started.

Resist the urge to add Kafka because Kafka exists. Every component you draw is one you can be asked to defend.

Stage 5 — Deep dive (12 min)

The interviewer will usually pick. If they don't, offer: "The interesting part here is the geo index — shall I go deeper there, or would you rather cover the write path?"

Offering a choice is itself a signal: it shows you know which parts are actually hard.

When you're in it, the standard axes to go deep on:

• The data structure — why this index, this partition key, this storage engine.
• The failure path — what happens when this component dies mid-request.
• The hot spot — the celebrity key, the peak-hour surge, the one shard doing all the work.
• The consistency question — what a reader can observe, and whether that's acceptable.
• The scaling limit — where this design stops working, and what replaces it.

Stage 6 — Bottlenecks & wrap (4 min)

Do not let the clock run out mid-sentence. At about the 40-minute mark, close deliberately:

"To summarise: partitioned by driver ID, Redis for live positions, Cassandra for history. The first thing to break under 10× traffic is the matching service, because it fans out across shards. If I had more time I'd add cell-based isolation per region, and I'd want to validate the 4-second ping interval — that assumption drives the whole write path."

Naming your own weakest assumption is one of the strongest possible closings. It shows you know the design is provisional and where it's load-bearing.

Things that come up in every round

"I don't know." Say it, then reason. "I haven't used Spanner in production. From what I know it uses bounded clock uncertainty and waits it out on commit — so I'd expect the cost to show up as commit latency." Confident reasoning from partial knowledge scores far better than a confident wrong assertion, and infinitely better than silence.

Being redirected. If the interviewer changes topic, they are not being difficult — they are steering you to what they need to assess. Follow immediately. Candidates who insist on finishing their point lose real points.

Getting a hint. A hint means you are off track. Take it, visibly: "Good point — that means the fan-out on write breaks for celebrity accounts, so let me handle those differently."

Running out of time. Better to have a complete shallow design plus one deep dive than a beautiful half-system. If you're behind at 25 minutes, say "I'll keep the rest at a high level so we have time to go deep on one part."

What to take away

• Budget the clock and say the budget out loud. Scope in five minutes, not twenty.
• Estimate to find the number that changes the design, then say what it changed.
• Write concrete APIs and commit to a partition key.
• Reach a complete simple system before improving any part of it.
• Offer a deep-dive choice; go two levels deep on data structure, failure, hot spots, and limits.
• Close deliberately at 40 minutes, naming the first thing to break and your weakest assumption.
• Drive. Silence is the floor being handed to you.