System Design Interview: Fast-Track in 48 Hours

What this sprint deliberately skips

This is the most useful table on the page, so it comes first rather than last. Everything below is real interview material that a 48 hour plan cannot buy you. Reading the list is how you decide whether the trade is acceptable.

Prerequisites

Five rows, not eight, because a reader with 48 hours cannot act on a longer list. Answer each Quick check in under a minute. Two or more misses and the honest advice is to move your round if you can, and to read Modern System Design if you cannot.

Time budget

The sprint is 48 wall-clock hours. Working hours are the part you spend at a desk. The two sums below are the whole method: working plus non-working equals 48, and the seven blocks in the plan sum to 48.

Learning objectives

Six objectives. Each is tested by exactly one numbered item in the mastery check, and the numbering matches: objective 1 is tested by mastery item M1.

1. Route yourself to one of three sprint tracks using the eight-question triage, and state which two blocks your track expands and which two it cuts, with the reason for each.
2. Deliver the first two minutes of a 45 minute round as four sentences that restate the prompt with a number, name the hard parts, scope something out, and ask one forking question, without naming a phase out loud.
3. Produce two numbers for any prompt in under three minutes, each followed by the design option it removes, and decline estimation in one sentence when no option would die.
4. Draw a v0 using only components from the eight-item toolkit, using the fewest the written requirements permit, then name the metric and the threshold at which it breaks and how you would observe it.
5. Sustain one deep dive for eight minutes on a prompt of your choice, naming a mechanism, a number derived in front of the interviewer, and one failure class named anywhere in this sprint.
6. Convert a scored self-mock into a next-block reading list using the remediation map, and name the sibling course that repairs each weakness after the round.

Warm-up retrieval

Three to five minutes, before you open anything else. Answer out loud. If all three are blank, that is data for the triage, not a reason to stop.

Q1. The hub states one hard rule about when a number is allowed to appear in your answer. State it.

Q2. In the hub's 45 minute clock, more than half the working minutes sit after one particular event. Which event, and which two phases are widest?

Q3. Reaching back to the hub's failure library: name the class where a system stays broken after the original trigger is gone, and the two design changes that prevent it.

The triage diagnostic

Two readers with the same deadline should not follow the same hours. Answer eight questions yes or no, count the yes answers, and read your track off the diagram.

1. Have you sat at least one real system design interview, not a mock, in the last 18 months?
2. Can you state a minute budget for a 45 minute round right now, without looking it up?
3. In the last month, have you drawn a system for another person on a whiteboard or shared canvas?
4. Can you convert 400 million requests per day into requests per second in your head, right now?
5. Can you name three failure classes and the design change that removes each?
6. Have you operated a service in production that had a paging alert attached to it?
7. Can you name the number that decides between adding a cache and adding a read replica?
8. In your last design discussion at work, did you remove a component rather than add one?

+---------------------------------------------+
| Count the yes answers from the eight above  |
+---------------------------------------------+
   |
   +-> +--------------------------------------+
   |   | 0 to 2 yes = Track A, first timer    |
   |   | more clock and toolkit, one dive     |
   |   +--------------------------------------+
   |
   +-> +--------------------------------------+
   |   | 3 to 5 yes = Track B, rusty          |
   |   | the published plan, unchanged        |
   |   +--------------------------------------+
   |
   +-> +--------------------------------------+
       | 6 to 8 yes = Track C, out of practice|
       | skim blocks 1 and 2, all the reps    |
       +--------------------------------------+

Caption: the triage router. Your yes count selects one of three tracks. Track A buys framing and vocabulary, Track B runs the published plan unchanged, and Track C skips most of the teaching and spends the hours on timed repetitions instead.

Working hours per block, by track

Same 48 wall-clock hours, allocated differently. Unused block time is rest, not spare study time.

What each track changes, and why:

• Track A expands hours 0 to 4 and 4 to 10, because a first timer's biggest loss is a round with no structure and no vocabulary. It cuts hours 26 to 34 to one deep dive instead of two, because a second dive you cannot hold adds nothing.
• Track B runs the plan as published. It is the calibration point for the other two.
• Track C cuts hours 0 to 4 and 4 to 10 to skim reading, because the material is already held. It expands hours 34 to 42 and the drill count, because its failure mode is a rusty performance, not a missing schema.

The 48 hours, block by block

+------+--------+--------+--------+--------+--------+------+
| Set  | Tools  | SLEEP  | Sprint | Dives  | SLEEP  |Taper |
| up   | + est  | + card | 3 cases| + mock | + fix  |+ mock|
| 4 h  | 6 h    | 8 h    | 8 h    | 8 h    | 8 h    | 6 h  |
+------+--------+--------+--------+--------+--------+------+
0      4        10       18       26       34       42    48

Caption: the shape of the sprint in wall-clock hours. Two of the seven blocks are sleep, which is 16 of the 48 hours, and they are not negotiable. The heaviest work sits in the two eight hour blocks between the sleeps, and the final block is a taper rather than a push.

Anchoring the blocks to real clock times

Hour 0 is 48 hours before your round starts. One worked anchoring, which is the case where the blocks land perfectly:

If your round is not at 14:00, the sleep blocks will not land on your night. Shift blocks 10 to 18 and 34 to 42 onto whatever eight hour window contains your normal sleep, and absorb the difference in the neighbouring blocks. Never move sleep to make room for study.

Hours 0 to 4: buy a clock and an opening

Hours 4 to 10: the toolkit and numbers that eliminate

Hours 10 to 18: sleep, and this block is load-bearing

Hours 18 to 26: three prompts, requirements to first breaking point

Hours 26 to 34: two deep dives, at real depth

Hours 34 to 42: repair, then sleep

Hours 42 to 48: taper

The minimum viable toolkit

This is the only teaching module in the sprint. Everything in it is chosen because it appears across most generalist prompts, and everything that appears in only one prompt has been cut.

1a. Predict first

Before reading on, commit to an answer. A candidate draws a load balancer, an application tier, a cache, a queue and a database, then reads the requirements. Which of those five boxes is most likely to be the one they cannot justify when asked, and why that one?

1b. The eight building blocks

Eight, not twenty. Each row carries the measurement that justifies it and the threshold below which it is over-engineering.

1c. The toolkit assembled

+---------+    +-------------+    +---------------+
| Client  |--->| App tier    |--->| Primary store |
+---------+    | stateless   |    | + replicas    |
               +-------------+    +---------------+
                  |     |                ^
                  v     v                |
          +---------+ +---------+  +-----------+
          | Cache   | | Queue   |->| Worker    |
          | hot set | | bounded |  | slow work |
          +---------+ +---------+  +-----------+
                          |
                          v
                   +---------------+
                   | Object store  |
                   | large values  |
                   +---------------+

Caption: the seven boxes most generalist prompts are built from, with the eighth (partitioning) being a property of the primary store rather than a box. The client calls a stateless app tier, which reads through a cache to a primary store with replicas, pushes slow work onto a bounded queue for a worker, and keeps large values in an object store. Almost every v0 in this sprint is a subset of this picture.

1d. Worked example

Prompt: "Design an internal document store for a company of 4,000 employees. People upload files and search them by title."

I narrate the decisions in the order I would say them.

Block one, purpose: establish that scale is not the problem here. 4,000 employees is GIVEN. Assume each does 20 document operations a working day, which is reasonable because a document tool is used in bursts rather than continuously. That is 80,000 operations a day, and 80,000 divided by 86,400 is under 1 per second. At a 5x peak that is under 5 per second.

That single number eliminates the load balancer as a scaling argument, eliminates the cache, eliminates partitioning, and eliminates the queue for throughput reasons. The most common error at this step is to compute the number and then draw the boxes anyway.

Block two, purpose: pick the smallest correct storage shape. Files are large and served by URL, so they go to an object store. Metadata (title, owner, timestamps, object key) is small, relational and queried by title, so it goes in one relational primary. That is two boxes, and the toolkit row for the object store is what justifies the split.

The common error here is putting file bytes in the database because it is one fewer box. It is one fewer box and it doubles your backup size, poisons your cache and slows your replication.

Block three, purpose: find the one thing that is actually slow. Extracting text from a PDF for search takes seconds. The caller does not need it to render the upload confirmation. That is exactly the queue row: acknowledgement now, work completes within a stated delay.

So the design is: app tier, object store, relational primary, one bounded queue, one worker. Five boxes, no cache, no partitioning, no CDN.

Block four, purpose: name the breaking point before being asked. The first thing to break is not throughput, it is the object store permission model, at the moment one document must be visible to some employees and not others. Observation: a support ticket, not a graph. That is worth saying, because naming a non-capacity breaking point is uncommon and it reads as experience.

1e. Fade the scaffold

Faded one. Prompt: "Design a service that emails a receipt after every purchase." Purchases are 300,000 a day (GIVEN). Blocks one and two are given; produce block three.

• Block one: 300,000 divided by 86,400 is about 3.5 per second, at a 4x peak about 14 per second. Rules out partitioning, rules out a cache, rules out horizontal anything for throughput.
• Block two: purchases already exist in a relational store. Receipts need a record of what was sent, so one small table.
• Block three: ?

Faded two. Prompt: "Design a leaderboard for a mobile game with 2 million daily players." Block one is given; produce blocks two and three.

• Block one: assume each player finishes 10 sessions a day, which is reasonable for a casual mobile title played in short bursts. 2,000,000 times 10 is 20 million score writes a day, which is 231 per second average and about 900 at a 4x peak. Reads: assume each player checks the board 5 times a day, so 10 million reads a day, 116 per second, 460 at peak.
• Blocks two and three: ?

1f. Check yourself

C1. A prompt gives you 40 reads per second and 6 writes per second. Which of the eight blocks are you allowed to draw, and what do you say when the interviewer asks where the cache is?

C2. Name the one block in the toolkit whose wrong use is most expensive to reverse, and say why.

1g. When not to use this

The toolkit itself has a threshold. Do not reach for it when the prompt is not a service.

1h. Six estimation drills, five minutes each

Do these in block 4 to 10. Write the arithmetic and the eliminated option before opening any answer.

E1. A product does 250 million API calls a day. Average per second, and what does it rule out?

E2. You store 5 million rows a day of about 400 bytes each, for 2 years. Size it and eliminate something.

E3. The availability target is 99.95 percent, measured monthly. Minutes of downtime, and what does it rule out?

E4. A read fans out to 6 services in parallel, each with a p99 of 200 ms. What happens to the combined p99?

E5. 12,000 reads per second at a 92 percent cache hit ratio. What does the origin see, and what does a deploy do?

E6. Two regions 8,000 km apart. What does a synchronous cross-region write cost, and what does that rule out?

1i. The five patterns

Five, and each carries its own threshold.

The delivery clock, compressed

The full version, including how the split moves by level and six situations where following it is wrong, is on the hub. This is the one screen you memorise.

The budget assumes a 45 minute slot loses about 5 minutes to introductions, tooling and your own closing questions, leaving 40 working minutes. That deduction is an assumption, and it is reasonable because nearly every remote round spends time on hellos and screen sharing.

The opening, as four sentences

Restate with a number. Name the two or three hard parts. State what you are dropping. Ask the one question whose answer changes the design most. Under sixty seconds spoken, and no phase name in it.

"So: a service that takes a long URL, returns a short one and redirects on lookup, at something like a hundred million redirects a day. The hard parts look like read latency on the redirect, key generation without collisions, and one link going viral. I am dropping analytics dashboards and custom domains unless you want them. Before I draw: do links ever expire, because that decides whether I need a deletion path at all?"

Three recovery scripts

Sprint case study 1: URL shortener

Done at sprint pace: about 25 minutes of thinking, not 90. The full nine-part arc is here, compressed, and the section ends by naming what a fuller answer adds.

The prompt (shortener)

"Design a service that turns a long URL into a short link, and sends anyone who visits the short link to the original."

Clarifiers that fork the design (shortener)

Requirements (shortener)

Functional: create a code for a URL and return it; resolve a code and redirect; record a click per resolution.

Numbers that eliminate (shortener)

V0: the smallest thing that works (shortener)

+---------+     +---------------+     +----------------+
| Browser |---->| App tier      |---->| Postgres       |
|         |<----| stateless     |<----| code -> url    |
+---------+     +---------------+     | 438 GB, PK     |
                                      +----------------+

Caption: V0 has three boxes. A browser calls a stateless app tier, which does one primary-key lookup in a single relational store and returns a redirect. No cache, no queue, no partitioning, because nothing in the stated numbers justifies them yet.

The breaking point, then V1

Breaking point: 18,400 reads per second at peak. What fails: primary CPU saturates on point lookups, connection pool wait climbs, and redirect p99 goes from single-digit milliseconds to seconds. How you observe it: query-level CPU attribution on the resolve statement, plotted against pool wait time at p99. This is capacity, not a herd.

+---------+   +-----------+   +---------+   +-------------+
| Browser |-->| App tier  |-->| Cache   |-->| Postgres    |
|         |   | local LRU |   | 22 GB   |   | primary +   |
+---------+   | 1 s TTL   |   +---------+   | replicas    |
              +-----------+                 +-------------+
                    |
                    v
              +-----------+
              | Click     |
              | queue     |
              +-----------+

Caption: V1 adds a 22 GB shared cache sized from the working set, a tiny per-instance cache with a one second time to live, read replicas, and a queue for click events. Five boxes, each added because a number above demanded it.

Deep dive one: sizing the cache and the hot-key ceiling

The dive is chosen because this prompt's whole interest is the read path. The two other sprint case studies dive elsewhere on purpose.

The working set is 21.9 GB, derived above. That fits two cache nodes with a replica, so the sizing question is settled in one line. The interesting number is the hot-key ceiling.

One viral link can take a large share of 18,400 reads per second. In a hash-partitioned cache that key lives on one node, so that node absorbs the spike while its peers idle. The local per-instance cache is what bounds it: with 80 app instances and a one second time to live, each instance can miss at most once per second for that key, so the shared cache sees at most 80 requests per second for it no matter how popular the link becomes.

The general form is worth memorising, because it generalises to every hot-key problem: shared-tier load per key equals instance count divided by local time to live. Raise the time to live to cut load, and pay for it in staleness.

Deep dive two: the redirect status code is a traffic decision

A 301 is permanent and browsers cache it, so repeat clicks never reach you. A 302 or 307 keeps every click on your servers. Redirect semantics are defined in RFC 9110 (June 2022).

That one choice produced the 18,400 reads per second in the first place. If analytics is dropped, 301 removes most of your repeat read traffic, and with it the cache tier, the replicas and the queue. It also removes your ability to ever disable a malicious link, which is the argument against it.

Saying this out loud is worth more than the cache sizing, because it shows you can see a product decision setting an infrastructure bill.

Failure modes and what you would measure (shortener)

Publish three indicators and no more: redirect success rate, redirect server-side p99, and shared cache hit ratio. Alert on error budget burn for redirect availability, not on raw error count. The 99.95 percent target is 21.6 minutes a month, derived as 0.05 percent of 43,200 minutes.

Re-check against the requirements: p99 under 50 ms holds at a high hit ratio because the miss path is one point lookup; 18,400 reads per second holds and could grow tenfold without a shape change, because the local tier caps per-key load; 438 GB holds on one primary, so the retention requirement needs no partitioning.

Where this is a simplification (shortener)

• Abuse is the actual hard problem. A shortener is a phishing tool by default, so real services check destinations at create time and re-check later. That makes the mapping mutable, which breaks the write-once assumption the design leans on.
• Bots inflate click counts. Link preview crawlers fetch every pasted link, often repeatedly.
• Key generation is skipped here on purpose. The sprint uses a counter passed through a reversible scramble and moves on. The full treatment, including why hash-and-truncate needs a uniqueness check anyway, the collision arithmetic and the block allocator, is in Modern, case study 1.

What a fuller answer adds (shortener)

Key space arithmetic and code length; a key allocation service and when not to build one; negative caching against scanners; custom domains and certificate issuance; and the deletion path that retention law requires. Read the deep version after the round.

Level delta (shortener)

Mid to senior: every number now removes an option and every box has a measurement behind it. Senior to staff: a product decision is priced, and at least one component is removed on evidence.

Sprint case study 2: home timeline

Chosen second because it is the prompt where the toolkit's fan-out pattern earns its place, and because its interesting number is a crossover rather than a capacity.

The prompt (timeline)

"Design the home timeline for a social app: the list of recent posts from the accounts a user follows."

Clarifiers that fork the design (timeline)

Requirements (timeline)

Functional: post; read the timeline in reverse chronological order; page backwards through it.

Numbers that eliminate (timeline)

That last row is the point of the whole case study. The threshold is derived from your own freshness budget and your own fan-out throughput, not memorised.

V0: the smallest thing that works (timeline)

+--------+    +-------------+    +------------------+
| Client |--->| Feed API    |--->| posts table      |
|        |<---| merge top50 |<---| idx author,time  |
+--------+    +-------------+    +------------------+

Caption: V0 is three boxes. The client asks the feed API, which reads the most recent posts for each followed author from one index and merges them in memory. This is correct for a small graph and is the design you should draw first even though you already know it breaks.

Breaking point, then V1 and V2 (timeline)

Breaking point one: 2.78 million index probes per second. Observation: timeline p99 correlated with followed-account count per user, while the store's CPU is dominated by index scans rather than by writes.

+--------+   +-----------+   +------------------+
| Author |-->| Post svc  |-->| posts table      |
+--------+   +-----------+   +------------------+
                  |
                  v
           +--------------+      +----------------+
           | Fan-out      |----->| timelines      |
           | bounded queue|      | one row per    |
           +--------------+      | user, capped   |
                                 +----------------+
                                        ^
+--------+   +-----------+              |
| Reader |-->| Feed API  |--------------+
|        |   | + merge   |
+--------+   | big posts |
             +-----------+

Caption: V1 and V2 together. A post is written once, then a bounded fan-out queue writes a capped list of post ids into each follower's timeline row, and the feed API reads one row per request. V2 is the extra arrow: accounts above the derived crossover skip fan-out, and the feed API merges their recent posts at read time.

Breaking point two: one account above 2.09 million followers. What fails is the freshness budget, not the system. Observation: alert on oldest-message age in the fan-out queue, never on queue depth, because depth tells you nothing about how late the last user will be.

Deep dive one: the crossover, derived live

This dive exists because the crossover is the one number in the prompt an interviewer cannot look up, and deriving it in front of them is the strongest thing you can do here.

The chain is four steps and takes about ninety seconds on a whiteboard.

• Peak posts per second, from daily active users and posts per user: 348.
• Median fan-out per post, from the median follower count: 200, giving 69,600 inserts per second at peak.
• The freshness budget, stated as a requirement: 30 seconds.
• Multiply: 30 times 69,600 is 2.09 million followers. Above that, this account cannot be fanned out in time.

What to say next matters as much as the number: "so the hybrid boundary is not a magic constant, it is my freshness budget times my fan-out throughput. If the product accepts five minutes of lag for celebrity posts, the boundary moves by a factor of ten and I may not need the second path at all."

Deep dive two: paging a list that changes while you read it

Chosen because it is the failure users actually report, and because it is a different class from anything in case study 1.

Offset pagination breaks on a mutating list. If three posts arrive between page one and page two, offset 50 now points three items further back, so the reader sees three duplicates. If posts are deleted, they skip items instead.

The fix is a cursor: an opaque token encoding the sort key of the last item returned, which for a timeline is the pair (created at, post id). The post id breaks ties when two posts share a timestamp, which happens more often than people expect at 348 writes per second.

Failure modes and what you would measure (timeline)

Indicators: timeline read p99, fan-out oldest-message age, and hydration cache hit ratio. Re-check: 200 ms p99 holds because a read is one row plus a cached hydration; 13,900 reads per second holds because it is one row read per request; the 30 second freshness holds for everyone below the crossover and is met by the merge path above it.

Where this is a simplification (timeline)

• Ranking changes everything. Most real timelines are ranked, which turns this into a retrieval and scoring problem. That is a different course: ML System Design.
• The follow graph is its own system. Reading a user's followers at fan-out time is a scatter-gather over a graph store, and it is the second hardest thing here.
• The full fan-out cost model, including the arithmetic of when precomputation stops paying and how the two paths are kept consistent, is in Modern, case study 3.

What a fuller answer adds (timeline)

The cost model in money per million timeline reads; duplicate suppression across pages; the follow-graph store; backfill order when the timeline row format changes; and the multi-region read story. All of it is post-round reading.

Level delta (timeline)

Mid to senior: the design stops being a shape and starts being a set of numbers. Senior to staff: the requirement itself becomes negotiable, and operational consequences drive the structure.

Sprint case study 3: chat with delivery receipts

Chosen third because it is the only prompt in the sprint where the interesting resource is connection state rather than storage or fan-out, so its dives cannot repeat the first two.

The prompt (chat)

"Design one-to-one and small-group messaging with delivery receipts, for a mobile and web client."

Clarifiers that fork the design (chat)

Requirements (chat)

Functional: send a message to a conversation; deliver to all participants' connected devices; store history; report delivered and read receipts.

Numbers that eliminate (chat)

V0: the smallest thing that works (chat)

+--------+    +---------------+    +-----------------+
| Client |--->| Message API   |--->| messages table  |
| polls  |<---| poll for new  |<---| conv id, seq    |
| 2 s    |    +---------------+    +-----------------+
+--------+

Caption: V0 is three boxes. Clients poll a stateless message API every two seconds, which reads any messages newer than the client's cursor from one store keyed by conversation and sequence. Correct, simple, and it fails at a number you can state.

Breaking point, then V1 (chat)

Breaking point: 1.5 million polls per second for 13,900 useful messages. What fails is efficiency and latency together: over 99 percent of poll responses are empty, and a two second poll interval cannot meet a 500 ms delivery target. Observation: ratio of empty to non-empty poll responses, plotted against delivery latency.

+--------+   +--------------+   +------------------+
| Client |==>| Gateway tier |-->| Message service  |
| socket |   | 60 nodes     |   | assigns seq      |
+--------+   +--------------+   +------------------+
                   ^                     |
                   |                     v
             +-------------+     +------------------+
             | Session map |     | Message store    |
             | user -> gw  |     | conv id, seq     |
             +-------------+     +------------------+

Caption: V1 has five boxes. Clients hold a persistent socket to one of 60 gateway nodes; a session map records which gateway holds each user; the message service assigns a per-conversation sequence number and writes to a partitioned store; delivery is a lookup in the session map followed by a push to the right gateway.

Second breaking point: a gateway node restarts and drops 50,000 connections at once. All of them reconnect immediately, and 60 nodes worth of coordinated restarts is a herd that can take the tier down. Observation: reconnect rate per second against deploy markers. The fix is full jitter on reconnect plus resume-from-sequence so a reconnect is cheap.

Deep dive one: where session state lives, and how a message finds a connection

Chosen because connection routing is the thing this prompt has that neither of the other two does.

Three options, and the choice is a trade between a lookup and a broadcast.

The number that decides it: gateway node count. At 60 nodes, broadcast costs 60 times the delivery work for zero lookups, which is a bad trade. At 5 nodes it is a good one, and saying that threshold out loud is the point.

The stale-entry case is the detail worth naming: the session map is updated on connect and on disconnect, and disconnects are not always clean. So the gateway must verify it actually holds the connection and reject if not, and the sender falls back to storing the message for offline delivery. Without that check you get silent message loss, which is the worst failure in a chat system.

Deep dive two: ordering, and why wall-clock timestamps are the wrong tool

Chosen because it is a correctness question rather than a capacity one, which makes it a different shape from every other dive in this sprint.

Two devices send into the same conversation at nearly the same moment. If each message carries the sending server's wall-clock timestamp and clients sort by it, two servers whose clocks differ by even tens of milliseconds can produce different orders on different devices. Ordinary clock drift is enough. That is the clock skew failure class.

The fix is a monotonic sequence number assigned per conversation by whichever component owns that conversation's writes. Clients sort by sequence, not by time, and the timestamp becomes display metadata only.

That last row is the compression worth showing: a read receipt is not a message, it is a number, so a participant reading 400 messages produces one update rather than 400.

Failure modes and what you would measure (chat)

Indicators: delivery latency from send acknowledgement to device receipt at p99, connection count per gateway, reconnect rate, and undelivered message age. Re-check: 500 ms p99 holds because delivery is one session lookup plus one push; 3 million connections hold across 60 nodes at the assumed 50,000 each; 58 TB per year holds in a partitioned store and not in a single primary.

Where this is a simplification (chat)

• End-to-end encryption changes the whole shape. The server stores opaque blobs, cannot search, and key distribution becomes the hard problem.
• Group membership changes mid-conversation raise questions about history visibility that this arc skips entirely.
• Multi-device sync and offline catch-up get one line here and a full treatment in Modern, case study 4.

What a fuller answer adds (chat)

Presence as its own subsystem with its own fan-out problem; push notification delivery to a device that is not connected; the media path for images and video; and a migration story for the sequence assignment when a conversation gets too hot.

Level delta (chat)

Mid to senior: each component is derived from a number rather than recognised from a pattern. Senior to staff: the failure of the mechanism, not the mechanism, drives the design.

Timed drills

Five prompts. Three are the same shape as the case studies; two are deliberately different and will feel worse. Do D1 to D3 in blocks 18 to 34 and D4 to D5 in the taper.

The stopwatch protocol

Set an actual timer. Speak out loud, do not think silently, because the round is a spoken performance and silent practice does not train it.

Those six segments sum to 25 minutes. Score yourself against the rubric immediately, while you still remember what you said.

The rubric

D1: rate limiter for a public API

D2: metrics ingestion for 200,000 hosts

D3: typeahead suggestions

D4: a running photo service, and a new constraint

Prompt. "We have a photo service on one relational primary at 60 percent CPU, serving 3,000 requests per second, with images in an object store. Product wants a public API with per-tenant quotas shipping next quarter. What changes?"

This one is brownfield and interleaved, and it draws on the toolkit, the hub's trade-off atlas and the rate limiter drill above.

D5: the answer is no

Prompt. "The team wants to add a message broker and a service mesh to an internal tool with 400 users and one deploy a week. Make the call."

The night before

Six lines. Do these at hour 46, then stop.

1. Confirm the round: time zone, joining link, drawing tool, and whether it is 45 or 60 minutes. Open the drawing tool once and draw one box in it.
2. Print or open the interview-day checklist and the three summary cards in a second window.
3. Say the four-sentence opening out loud once, on a prompt you have not practised. Do not evaluate it.
4. Write your one deep dive on a card in three words, so you can see it while you talk.
5. Set out water, paper and a pen. Paper matters even in a remote round, for the arithmetic.
6. Sleep. If you have to choose between a seventh study hour and a seventh hour of sleep, the sleep wins and it is not close.

The morning of

Five lines, in this order.

1. Eat something. A design round is 45 minutes of continuous talking.
2. Read the three summary cards once, at reading speed. Do not re-derive anything.
3. Say the opening out loud twice, once on a prompt you know and once on one you do not.
4. Read the three recovery scripts. These are the highest-value forty seconds of the morning, because they are what you will actually need.
5. Ten minutes before: close every tab except the drawing tool and the checklist. Stand up, walk once around the room, sit down.

In the first minute of the round, ask two ordinary scheduling questions if nobody has said: is this 45 or 60 minutes, and would they like you to drive or to be interrupted. Both change how you spend the clock, and both are free to ask.

After the interview

The sprint bought you a performance. It did not buy you depth, and the gap is exactly the omission table at the top of this page. Convert it while the round is still fresh.

Within two hours of the round, write down: every question you could not answer, every number you invented, and the one moment you felt the interviewer lose interest. That document is worth more than any course, because it is the only genuinely personalised study plan you will get.

The delayed self-check

Answer these from memory a week after the round, with this page closed. If you can, the sprint became knowledge rather than a performance.

12. Mastery check and remediation map

Six short-answer items, one per learning objective. Write your answer before opening the block.

M1 (Objective 1, routing yourself). You scored 7 yes answers on the triage. Which two blocks does your track expand, which two does it cut, and why each?

M2 (Objective 2, the opening). Give the four sentences for a prompt you have not practised: "design a service that stores and serves user avatars."

M3 (Objective 3, numbers that eliminate). A prompt gives you 90 million events a day. Produce one number that eliminates something, then give the sentence you would use if nothing could be eliminated.

M4 (Objective 4, v0 and its breaking point). A prompt states 1,200 reads per second, 40 writes per second, 300 GB of data, and a requirement that a write is visible to the writer immediately. Draw the v0 in words, then name the breaking point in the required form.

M5 (Objective 5, holding a dive). Pick one of the three sprint case studies and give the three things your eight-minute dive must contain, with a concrete example of each.

M6 (Objective 6, converting scores into a plan). You scored Below bar on "Depth in one area" across all five drills, and At bar elsewhere. State your next block, and the sibling course you open after the round.

Threshold. Five of six, with M3 and M4 among them. Those two are weighted because eliminating numbers and stated breaking points are what separate a described architecture from a designed one, and they are also the two things a 48 hour sprint can genuinely install.

13. Common mistakes catalogue

Technical mistakes cost a follow-up. Delivery mistakes cost the round. The last four rows are the delivery ones, and they are where a sprint candidate loses most often.

14. Interview-day checklist

One screen. Nothing here is new.

Minute budget, 45 minute round. Open 0 to 2. Clarify and requirements 2 to 9. Numbers 9 to 11. V0 11 to 19. Breaking point and V1 19 to 27. One dive 27 to 36. Failure modes and wrap 36 to 40.

The first four sentences. Restate with a number. Name the hard parts. Say what you are dropping. Ask the one question that forks the design.

Five clarifying questions that generalise across prompts

1. Read heavy or write heavy, and roughly what ratio?
2. Does a stale read hurt anyone, and how stale is acceptable in seconds?
3. What is the largest single entity: the biggest tenant, the biggest producer, the hottest key?
4. Is this greenfield, or is there a running system I should not break?
5. What would make this a failure in production, as opposed to wrong on the whiteboard?

Drawing order. Client, then the one service that does the work, then the store. Stop. Leave the right third of the canvas empty, because that is where V1 goes. Do not draw a load balancer, a cache or a queue until a number on the board demands it.

Three recovery scripts. Stuck: state the assumption and move. Disagreed with: update the design out loud. Out of time at minute 34: close the dive and protect the wrap.

Before you finish, three sentences. Name one trade-off you made and its cost. Name what you skipped and why. Name the one thing you would measure first in production.

15. If you have less than 48 hours

The sprint has branches. Each one names what it drops and what that costs.

The pattern across all four branches is the same, and it is the argument of this whole page: delivery is bought first because it is cheapest to install and most expensive to lack. Depth is bought last because it takes the longest and is worth the most.

16. Reference block

Lookup material only. Nothing here is explained for the first time.

16a. The eight decisions this sprint carries

The full set of twenty-two is in the hub's trade-off atlas. These eight cover most sprint prompts.

16b. The six numbers, with derivations

16c. ASCII glyph legend

16d. Review cards

Copy this block. One fact or one decision per card.

1. A number may appear only if the next sentence kills an option.
2. Seconds in a day: 86,400. Peak is 2x to 5x average.
3. Cache earns its place above roughly an 80 percent hit rate.
4. Replicas add read capacity and lag, never write capacity.
5. Fan-out crossover = freshness budget x fan-out throughput.
6. Hot key ceiling = instance count / local time to live.
7. Partition key is the hardest decision to reverse. Make it last.
8. Queue = acknowledgement now. It hides failure, not latency.
9. Outbox = event written in the same transaction as the state.
10. Order by sequence, never by wall-clock time.
11. Alert on oldest-message age, never on queue depth.
12. Metastable = the degraded state generates its own load.
13. Breaking point = what fails, at what number, how observed.
14. 99.95 percent monthly = 21.6 minutes of downtime.
15. Say what you skipped, before the interviewer asks.

16e. One-page summary cards

Card 1, URL shortener

• Inputs: 2 million links a day, 200 to 1 reads, 3 year retention, 200 byte rows.
• 92 writes per second at peak rules out write sharding. 18,400 reads per second at peak rules out serving from the primary. 438 GB rules out partitioning for size. A 21.9 GB working set sizes the cache at two nodes.
• V0: client, app tier, one store. V1 adds a 22 GB cache, a one second local tier, replicas and a click queue.
• Dive: hot-key ceiling equals instance count over local time to live. Second dive: 302 versus 301 sets the entire read bill.
• Failures: cache stampede, hot key, thundering herd, retry storm.

Card 2, home timeline

• Inputs: 50 million daily users, 8 reads and 0.2 posts each, 200 median followers, 30 second freshness.
• 13,900 peak reads times 200 followed accounts is 2.78 million probes per second, which kills pull at read. 348 peak posts times 200 followers is 69,600 inserts per second. Crossover is 30 times 69,600, so 2.09 million followers.
• V0: pull at read. V1: precomputed capped id lists. V2: read-time merge above the crossover.
• Dive: derive the crossover live. Second dive: cursor on (created at, post id).
• Failures: unbounded queue growth, hot key, head-of-line blocking, thundering herd.

Card 3, chat

• Inputs: 10 million daily users, 40 messages each, 30 percent connected at peak, 400 byte records.
• 3 million connections at 20 KB is 60 GB, so 60 gateway nodes at an assumed 50,000 each. 1.5 million polls per second for 13,900 useful messages kills long polling. 58 TB a year kills a single relational primary.
• V0: polling. V1: gateway tier, session map, per-conversation sequence, partitioned store.
• Dive: session map versus broadcast, decided by node count. Second dive: sequence numbers, because clock skew reorders devices, and receipts collapse into cursors.
• Failures: thundering herd on reconnect, clock skew, head-of-line blocking, gray failure.

17. What this course does not cover

Beyond the omission table at the top, which lists what a 48 hour budget cuts from a generalist round, these are outside the page entirely.

Free material we do not control, with editions and dates, for after the round:

• Designing Data-Intensive Applications, Martin Kleppmann, O'Reilly, 2017. The single best book for the material this sprint omits, particularly replication, partitioning and consistency.
• Site Reliability Engineering, Google, O'Reilly 2016, free online at sre.google/sre-book. Chapters 4 to 6 are the source for service levels and alerting.
• The Site Reliability Workbook, Google, O'Reilly 2018, free online at sre.google/workbook. The practical companion, including error budget policy.
• RFC 9110, HTTP Semantics, June 2022, for redirect and caching semantics.
• In Search of an Understandable Consensus Algorithm, Ongaro and Ousterhout, USENIX ATC 2014, if you want the consensus material this sprint drops.
• The donnemartin/system-design-primer repository on GitHub is a widely used free community resource. It is a living repository with no fixed edition, so check its recent commit history before trusting any specific figure in it.

18. Provenance

Last reviewed: 1 August 2026. Any page in this section whose last-reviewed date passes nine months is flagged for review rather than quietly left in place.

Changelog, most recent first

Found a problem? Open an issue or a pull request at github.com/datascienceinterviews/datascienceinterviews.github.io/issues. Disputed numbers, dead links, better derivations and missing counter-arguments are all in scope.

All content on this page is original. Research informed which topics belong here; no prose, framework, acronym, example, table or diagram is derived from any paid course. Primary sources are cited inline with their edition and year, and any claim we could not source is either labelled as an assumption or is not on the page.