System design

A system design answer is a set of decisions, each tied to a number and each with a named failure. Every box solves one problem and creates another: a cache absorbs reads and must then be invalidated; a quorum survives a lost node and slows writes; a queue lets a fast producer outrun a slow consumer and makes delivery semantics yours. One rule runs through all of it: never draw a box whose number is not on the page.

Start here: the priority spine

For: SDE-1 and up.

Context. Common designs come first, and each reuses blocks from the ones before.

Know cold means you can say the skeleton from memory, defend it against the pushback bank and draw the boxes in three minutes. For any other prompt, use the unseen-prompt method near the end.

If you are short of time. Two hours: estimation and the block table, then say the eight skeletons aloud once. Lesson 5 sets the weeks beyond that; spend them on the pushbacks and on timed 45-minute runs scored with the rubric.

Eight spoken skeletons

Each follows the round's clock in minutes, from clarifying (0 to 5) to cost and paging (40 to 45). Say each aloud in two minutes. Cost lines sum nodes from "What one box handles", two thirds busy, at the Operate-it prices; a count marked "assumed" is a choice, not derived from the table.

Design 1: URL shortener

 0-5   Create, redirect, expiry, delete. A code is never reused.
       Analytics, abuse scanning and login are out. p99 under
       100 ms is my assumption.
 5-10  100 million new links a month, 100 reads a write (assumed):
       116 creates and 11,574 redirects a second at peak; 3.0 TB
       in five years (500 B a link). So: reads win 100 to 1; cache first.
 10-28 Load balancer, stateless app, cache by code, store sharded
       by code on a hash ring, and an ID service handing out blocks.
 28-40 Offer: the code. Base 62, 7 characters is 3.52 trillion.
       Fail: a stale replica says 404 (check the primary first);
       the cache dies and the store takes all 11,574 a second
       at peak (the six shards are sized for it).
 40-45 About Rs 8.96 lakh a month: 18 store nodes (six shards,
       three copies) Rs 7.2 lakh, 8 app servers (assumed)
       Rs 96,000, 3 cache nodes (one a zone) Rs 48,000, 5.0 TB
       of egress Rs 32,000. Page on redirect errors above 1%
       for 5 minutes.

Rate limiter

 0-5   Limit per API key, at the gateway, per plan. Answer allow
       or reject with retry-after. Billing-grade metering is out.
 5-10  50,000 customers at 1,000 a minute; 40,000 checks a second
       at peak (assumed); a 2 ms p99 budget inside a 100 ms call;
       400 MB for a log against 0.8 MB for a counter.
       So: the sliding counter, one atomic script per check.
 10-28 Gateway calls the limiter; counters in a sharded store;
       the limit table per plan shipped to gateways as config.
 28-40 Offer: the race. Read, compare, write lets two gateways
       pass the 100th; check and decrement in one script.
       Fail: the store dies (local limit, limit over gateways);
       one key past what its shard runs, say 100,000 a second
       (lease 100 tokens at a time; 5,000 a second needs nothing).
 40-45 About Rs 96,000 a month: six cache nodes at Rs 16,000,
       three shards with a replica each, a third busy at peak.
       Page on limiter p99 above 2 ms and the fail-open rate.

Design 6: notifications

 0-5   Which channels, who sends, how many, what latency classes,
       what must never happen. OTP in 5 s; no send after opt-out.
 5-10  50 million users x 5 a day: 2,894 sends a second; a
       campaign of 10 million in 10 minutes, 16,667 a second;
       OTP within 5 seconds. So: separate lanes, not one queue.
 10-28 One API with an idempotency key; per-channel queues per
       priority; workers check preferences at send time, render,
       call the provider; receipts update a status table.
 28-40 Offer: the campaign against a 2,000-a-second provider.
       83 minutes for the campaign; OTP has its own quota.
       Fail: a provider dies (fail over; an OTP may repeat, a
       payment alert checks status first); a send after opt-out
       (check preferences at send time, not at enqueue).
 40-45 About Rs 14.48 lakh a month, plus Rs 3 crore of SMS. Page
       on OTP p99 above 5 seconds.

Design 2: news feed

 0-5   Post, follow, read a feed newest first. Ranking is out
       today; say it may come next quarter.
 5-10  300 million daily users reading 5 times: 52,083 feed reads
       a second at peak. 50 million posts a day at 200 followers:
       pushing every post is 347,222 writes at peak (115,741 on
       the mean); one star's post is 20 million. So: push for
       most authors, pull for the large ones.
 10-28 Post store; fan-out queue and workers; timeline cache per
       user; a feed service that merges in large authors on read.
 28-40 Offer: the threshold, 10,000 followers, assumed. If the top
       1% hold 60% of follow edges (assumed), pushing the rest is
       138,889 writes a second at peak, 46,296 on the mean.
       Fail: an author just under the threshold posts and
       floods the fan-out queue (lower the threshold);
       my own post missing (write it to my timeline at once).
 40-45 Rs 51.2 lakh to Rs 94.4 lakh a month: 90 to 225 memory
       nodes of 64 GB for 5.8 to 14.4 TB of timelines, Rs 28.8
       to 72 lakh; assumed: 100 app and fan-out servers Rs 12
       lakh, 20 store nodes Rs 8 lakh, 6 brokers Rs 2.4 lakh.
       Page on queue lag above 30 seconds.

Design 4: chat

 0-5   One-to-one and groups up to 256; sent, delivered, read;
       one order per conversation; offline sync. Media out.
 5-10  500 million daily users x 40 messages: 694,444 a second at
       peak; 2.6 deliveries each, 1.8 million a second; 100 million
       sockets on 1,500 gateways, two thirds full.
       So: the hard parts are sockets and the sequence number.
 10-28 WebSocket gateways and a registry of who is where; a chat
       service appends to a per-conversation log, then delivers.
 28-40 Offer: ordering. One writer per conversation numbers it;
       a client that sees 40 then 42 asks for 41.
       Fail: a gateway dies (67,000 reconnect with jitter);
       a crash after append, before delivery (sync on reconnect).
 40-45 About Rs 2.93 crore a month: 1,500 gateways Rs 1.8 crore;
       70 log shards x 3 = 210 nodes Rs 84 lakh; 30 days at 200 B
       x 3 copies = 360 TB on block storage, Rs 28.8 lakh. Page on
       send-to-delivered p99 above 2 seconds.

Design 3: payments ledger

 0-5   Pay a person or a merchant; bank payouts in scope; money
       never moves twice and never half-moves. Data stays in India.
 5-10  2,400 transfers a second at peak; 10.1 TB a year; 69
       million idempotency keys a day. So: not a scale problem.
 10-28 Double-entry rows; the key, the entries and an outbox row
       in one transaction; the bank leg as a saga from the outbox.
 28-40 Offer: the bank times out. Pending, never a false failed;
       ask the bank by my transfer id; compensate on a no.
       Fail: a crash between the effect and the key (one commit);
       two payments overdraw one account (conditional update).
 40-45 About Rs 8.42 lakh a month at year end. Page on any
       unbalanced transfer and on pending past the bank's window.

Design 7: checkout and a flash sale

 0-5   1,000 units, 2 million people at noon, one per buyer.
       Never oversell; a late payment is refunded.
 5-10  200,000 attempts a second; one stock row clears about 500
       holds a second; 20 rows clear 10,000. So: stop the crowd
       at the edge, admit twice the stock, split the row.
 10-28 CDN waiting page with a sold-out flag; a gate of 2,000
       tokens; one transaction takes a unit and writes the hold,
       the order and an outbox row; the ledger's saga pays.
 28-40 Offer: the guard. avail >= 1 in the WHERE clause, checked
       again after the lock wait. Fail: payment after expiry
       (refund); a Redis failover losing a decrement (DB decides).
 40-45 About Rs 5.84 lakh a month: 30 app servers Rs 3.6 lakh, 3 SSD
       database nodes Rs 1.92 lakh, 2 cache nodes Rs 32,000; each
       sale's 10 minutes add 120 million CDN requests, Rs 9,600.
       Page on sold above stock and on an expired hold older
       than 1 minute.

Design 5: ride matching

 0-5   Drivers report every 4 seconds; a rider asks; offer to a
       good nearby driver for 10 seconds. Pricing and ETA out.
 5-10  1 million drivers online, one update every 4 seconds:
       250,000 updates a second; 100 MB of latest positions;
       about 5% of updates cross a cell. So: write rate is the
       problem; keep positions in memory, sample a trail.
 10-28 Location service keyed by driver; an in-memory index from
       cell (a map square) to drivers; a matcher that reads about nine cells.
 28-40 Offer: one driver, two riders. Compare-and-set the driver
       from available to offered, with a lease.
       Fail: a driver goes silent (dropped after 12 seconds
       without an update); two matchers race (one CAS wins).
 40-45 About Rs 10.45 lakh a month: 38 gateways Rs 4.56 lakh, 8
       position shards x 2 = 16 cache nodes Rs 2.56 lakh; 6 index
       nodes Rs 1.92 lakh and 10 matchers Rs 1.2 lakh, assumed;
       the trail kept 30 days (assumed), 13 TB, Rs 20,800. Page
       on match-found rate below its band and location lag
       above 10 seconds.

API and tables for the five card designs

What goes on the board at minutes 10 to 15.

Next stop: Capacity estimation: the arithmetic you do out loud, 3 min

Capacity estimation: the arithmetic you do out loud

For: SDE-1 and up; interns facing a light design question.

Context. An estimate exists to find the number that decides the design: at 39 writes and 3,858 reads a second, the reads are what you design. A day has 86,400 seconds; rounding to 100,000 makes every rate about 14% too low, so round only if you say which way the error runs. A peak factor, usually three, is your assumption. Three formulas cover most rounds: rate = count / seconds in the window x peak factor; bytes = count x size x copies x days kept; nodes = load / per-node budget.

Bandwidth is rate x bytes x 8 bits; take a 10 Gbit/s card as 7 usable (assumption). Memory is items x (payload + overhead) x copies.

What one box handles

Every design here takes its per-node budget from this table, the author's estimate (not measured): round numbers for small requests, to be replaced by a load test. Each tier gets 1.5 x peak / budget nodes, so it runs two thirds busy.

Next stop: Building blocks: one trade-off table, 2 min

Building blocks: one trade-off table

For: SDE-1 and up; interns facing a light design question.

The rows are the author's reading of standard practice.

Next stop: The API layer and security at each hop, 2 min

The API layer and security at each hop

For: SDE-1 and up.

The rows are the author's reading of common practice; codes and header names are a choice, so say "for example".

OAuth. OAuth 2.0 grants an app scoped access to a user's data without their password: after consent the app swaps a short-lived code, server to server, for an access token; PKCE makes a stolen code useless. OpenID Connect adds an ID token saying who the user is (the author's reading of the standards).

Next stop: Consistency: CAP, PACELC and the models, 3 min

Consistency: CAP, PACELC and the models

CAP. Seth Gilbert and Nancy Lynch proved a formal version of Eric Brewer's conjecture in 2002 (the author's reading). C is linearizability, A is a non-error answer from every live node, P is a network that may lose messages. During a partition a system cannot keep both C and A. It is not "pick two": partitions are not optional, and it says nothing about latency.

PACELC. Daniel Abadi (IEEE Computer, February 2012) adds the other half: if Partitioned, trade Availability against Consistency; Else, trade Latency against Consistency, a trade paid on every request. His 2012 classes under default settings: Dynamo and Cassandra PA/EL, VoltDB PC/EC, MongoDB PA/EC. Defaults change, so date them.

A quorum with R + W > N is not linearizable by itself: concurrent writes, a write that failed after reaching some replicas, or a sloppy quorum can let one read see a value a later read does not (the author's reading of the Dynamo paper).

Isolation concerns concurrent transactions on one database. PostgreSQL 18 (documentation read 1 Nov 2026) defaults to Read Committed; its Repeatable Read is snapshot isolation. Write skew is two transactions reading the same facts, writing different rows and together breaking a rule.

None allows a dirty read. The stronger levels fail with SQLSTATE 40001, and the documentation says to retry the whole transaction.

One writer: fencing and leader election. A lease is a lock that expires, so a holder paused by garbage collection can wake after expiry and write anyway. Martin Kleppmann's essay (8 Feb 2016, read 1 Nov 2026) gives the fix, a fencing token: the lock service hands out a number that rises with every grant, and the storage rejects a write carrying a lower number than it has seen. Raft (read 31 Oct 2026) does the same with terms: a leader needs a majority, a node votes once per term, and an older term is rejected, so a cut-off old leader commits nothing. Put an odd number of voters in three failure domains.

Next stop: Two-phase commit versus a saga, 1 min

Two-phase commit versus a saga

Context. Two-phase commit (2PC) asks every participant to make its change durable, hold its locks and vote, then tells all to commit or all to abort. Jim Gray and Leslie Lamport (2004, read 2 Nov 2026) name the weakness: if the coordinator fails, a participant that voted yes must wait, holding locks. Their Paxos Commit uses 2F + 1 coordinators to survive F failures.

A saga gives up isolation instead. Hector Garcia-Molina and Kenneth Salem (SIGMOD 1987) define it as a sequence of local transactions, each with a compensating transaction; on a failure the compensations for completed steps run in reverse, and other transactions may see a partial saga.

Choose. One database: a local transaction. Shards of a store with distributed transactions: its 2PC, naming the blocking risk. Services or companies: a saga, with idempotent compensations, the irreversible step last and the in-between state shown as "pending".

The outbox. A service that commits and then publishes can crash between the two. The outbox writes the event as a row in the same transaction; a relay publishes it and marks it sent, at least once, so consumers drop repeats by event id. Never promise exactly-once end to end.

Next stop: The Operate-it block that closes every design, 1 min

The Operate-it block that closes every design

Context. The Google SRE Workbook (re-read 2 Nov 2026) defines canarying as "a partial and time-limited deployment of a change in a service and its evaluation", kept small because harm scales with traffic: a 20% error rate on a 5% canary is about 1% overall. So every design ends with four lines, in two minutes.

1. Roll out and roll back. A canary or a flag at 1%, compared on the two or three metrics that mean user harm; what flips it back, and how fast.
2. Blast radius. What a bad deploy, config or dependency can break, and the wall that stops it (a shard, a tenant, a region, a bulkhead).
3. Watch. Three signals tied to user harm: not "CPU" but "messages older than 5 seconds". Name the one that pages.
4. Monthly cost line. An order of magnitude and the item that dominates. Every design prices from one invented list (assumption): Rs 12,000 a month for an app server; Rs 16,000 for a 32 GB cache node, Rs 32,000 for a 64 GB memory node; Rs 40,000 for a store node on network disk, Rs 64,000 on local SSD; Rs 8 per GB-month of block storage, Rs 1.6 of object storage; Rs 6.4 per GB of egress; Rs 80 per million CDN requests. A node's price includes a 1 TB disk; a store holding more than 1 TB a node keeps all its data on block storage instead, on network-disk nodes. In a real round, use the day's rate card.

Next stop: Design 3: a payments ledger, 5 min

Design 3: a payments ledger

Requirements. Accept a payment request that debits one account and credits another, with a status of pending, posted or failed. Every movement balances. A retry of the same request moves money once. A balance can be read at any time; a mistake is corrected by a reversal, never an edit. Out of scope: card data handling, tax and currency conversion, each owned by another system and said aloud.

Estimate. Assumption: 800 transfers a second on average, three times that at peak. Computed: 2,400 a second at peak; 69.1 million transfers a day; 25.2 billion a year. Two entries per transfer gives 4,800 entry inserts a second at peak, 50.5 billion rows a year; at an assumed 200 bytes a row that is 10.1 TB a year and 70.6 TB over seven years. Idempotency keys kept for 24 hours at 800 a second is 69 million keys a day, so the idempotency store is a sized table of its own. So: throughput is modest; the difficulty is correctness when a step half-completes, and when a bank's answer comes late or never.

Interface and data. POST /v1/transfers with an Idempotency-Key header returns 202 and status pending (the bank leg is slow) or 201 posted. GET /v1/transfers/{id} returns status and entries. GET /v1/accounts/{id}/balance returns posted and pending amounts. POST /v1/transfers/{id}/reversals makes the reversing transfer. The tables:

accounts(account_id, currency, status)
transfers(transfer_id, idempotency_key UNIQUE, status, request_hash,
          created_at, updated_at)
entries(entry_id, transfer_id, account_id, direction D|C, amount,
        currency, posted_at)       -- sum(D) = sum(C) per transfer
outbox(event_id, transfer_id, payload, sent_at NULL)
idempotency(key, response, created_at)   -- kept 24 h or more

The transfer row, its two entries and its outbox row commit in one database transaction, so a half-written transfer is impossible on one shard.

The relay delivers to the bank at least once, so the transfer id is the bank's idempotency key (an assumption to confirm with the bank).

Failures (SDE-2). Double posting is blocked by the unique key on the transfer and the idempotency key. Across shards, a saga with a compensating reversal prevents a partial posting. An overdraft: check the balance and write in one transaction, with a row lock on the account or a conditional update; say which (the write-skew example under consistency shows why). A reconciliation job compares the bank's statement file against the entries and sends every difference to a break queue for a person; it never edits posted entries.

Senior depth (adds). Three deep dives. Stored versus derived balance: a stored balance is fast to read and must be updated in the same transaction as the entries; a derived balance, summed from entries, is always right and slower; a snapshot plus the sum since the snapshot is the usual middle (author's reading). Sharding by account versus by transfer: by account makes a balance read one shard but puts a transfer between two accounts on two shards; by transfer keeps one transfer's entries together but makes balance reads scatter. Pick one and state its cost. The hot row: a synchronous commit to a second region holds an account's row lock about 62 ms (2 + 60), so one account takes about 16 locked debits a second, not 500; the node still runs 1,000, because group commit shares the round trip (Little's law: 1,000 x 0.062 s is 62 in flight). So credits append without the lock, only debits lock, and a payout pool debited 100 times a second splits into 1.5 x 100 / 16, so 10 sub-accounts. At ten times the load, 24,000 transfers a second at peak, the outbox relay and the bank's own rate limit become the bottleneck before the database; say which limit you would ask the bank for.

Next stop: Design 6: a notification system, 4 min

Design 6: a notification system

Context. The prompt is vague on purpose, so the first move is five questions that become numbers.

The design. Producers call one API with a template id, a recipient, a channel list, a priority and an idempotency key. The service writes the request, then fans it into per-channel queues, one set per priority: a one-time password must never wait behind a campaign, so the priority lanes are separate queues with separate workers, not one queue sorted. A worker checks the user's preferences and quiet hours at send time (not at enqueue time, since a campaign may sit for an hour), applies a per-user cap (for example 3 marketing messages a day), renders the template, calls the provider, and records the result. Providers answer with a message id and later a delivery receipt on a webhook; the status table moves queued, sent, delivered or failed. Retries back off with jitter up to a limit, then go to a dead-letter queue. The dedupe key is checked before the provider call and passed to a provider that takes one, since a timeout may have sent. Two SMS providers with a health check and a failover.

Deep dives. The campaign burst of 16,667 a second against a provider that accepts 2,000 a second (assumption): the queue absorbs it, the campaign takes 10,000,000 / 2,000 = 5,000 seconds, 83 minutes, and the OTP lane is unaffected because it has its own workers and its own provider quota. Fan-out of one request to a million users is a job that walks a segment in pages and writes per-user rows, with a cursor so a crash resumes. Cost is the surprise. If 1% of the 250 million a day goes by SMS, that is 2.5 million at an invented Rs 0.4, Rs 10 lakh a day, Rs 3 crore a month, far above the infrastructure, so the product rule "push first, SMS only for OTP and fraud alerts" is a design decision worth Rs 3 crore.

Next stop: Recovery, SLOs and migrations: one table, 1 min

Recovery, SLOs and migrations: one table

Next stop: Overload: retry budgets, deadlines, shedding, breakers, 1 min

Overload: retry budgets, deadlines, shedding, breakers

For: SDE-3, Staff, Principal.

Context. Overload gets worse when every caller retries. Rows one to three follow the Google SRE book (read 4 Nov 2026); the breaker row is the author's reading.

Page on the shed rate and the retry ratio, not only on errors.

Next stop: A senior-bar model answer: a rate-limiting service, start to finish, 8 min

A senior-bar model answer: a rate-limiting service, start to finish

Context. An invented interview, condensed to the exchanges that matter. Lines marked Signal say why a Senior reader would credit the sentence. Cover the candidate's lines and answer each interviewer line aloud first.

The four algorithms, and the race run

The race needs a gap between the read and the write, a store round trip; on one machine with no gap, get-then-set leaks almost nothing. The program gives eight gateways a limit of 100, puts a 50-microsecond pause where the round trip would be, and runs three checks.

import java.util.concurrent.CountDownLatch;
import java.util.concurrent.atomic.AtomicInteger;
import java.util.concurrent.locks.LockSupport;

class RaceTest {
  static final int LIMIT = 100, GATEWAYS = 8, TRIES = 100;
  static final AtomicInteger count = new AtomicInteger();
  static final AtomicInteger allowed = new AtomicInteger();

  // Atomic: the store checks and adds in one step (a Lua script).
  static synchronized void checkAtomic() {
    if (count.get() < LIMIT) {
      count.incrementAndGet();
      allowed.incrementAndGet();
    }
  }

  // GET, a store round trip (50 microseconds), then SET or INCR.
  static void checkGap(boolean incr) {
    int seen = count.get();                  // GET
    LockSupport.parkNanos(50_000);           // the network gap
    if (seen < LIMIT) {
      if (incr) count.incrementAndGet();     // INCR: no update lost
      else count.set(seen + 1);              // SET: overwrites others
      allowed.incrementAndGet();
    }
  }

  static int run(Runnable check) throws InterruptedException {
    count.set(0); allowed.set(0);
    var start = new CountDownLatch(1);
    var done = new CountDownLatch(GATEWAYS);
    for (int g = 0; g < GATEWAYS; g++) {
      Thread.ofPlatform().start(() -> {
        try { start.await(); } catch (InterruptedException e) { return; }
        for (int i = 0; i < TRIES; i++) check.run();
        done.countDown();
      });
    }
    start.countDown();
    done.await();
    return allowed.get();
  }

  public static void main(String[] args) throws Exception {
    int atomic = run(RaceTest::checkAtomic);
    int set = run(() -> checkGap(false));
    int incr = run(() -> checkGap(true));
    if (atomic != LIMIT) throw new AssertionError("atomic " + atomic);
    if (set <= 2 * LIMIT) throw new AssertionError("set " + set);
    if (incr <= LIMIT || incr > LIMIT + GATEWAYS - 1)
      throw new AssertionError("incr " + incr);
    System.out.println("atomic=" + atomic + " set=" + set + " incr=" + incr);
  }
}

Run with java --source 21 RaceTest.java on 4 Nov 2026, ten runs: atomic=100 every time; set 788 to 800 and incr 106 or 107, varying with thread timing. SET writes the count it read plus one over the others' increments, so the count stays under 100 and nearly every try passes. INCR loses no update, so only the reads in flight as the count nears 100 leak: at most 99 + 8 = 107.

Next stop: SDE-2 against SDE-3: where each answer can stop, 1 min

SDE-2 against SDE-3: where each answer can stop

For: SDE-1 (one line below the table), SDE-2 and SDE-3.

SDE-1: enough. The SDE-2 column for scope, numbers and design, plus one failure with what the user sees; no deep dive is expected in a light design question (author's estimate, not measured).

Next stop: What changes at Staff, 3 min

What changes at Staff

For: Staff and Principal; SDE-3 readers who want the next bar. Lesson 12 covers the rest of a Staff loop.

Context. In the author's reading, Staff evidence is what the candidate raises before being asked: the two hard parts, the failure classes with numbers, the cost, the migration and the owner.

Under every cell: the three failure classes (a component dies, a step half-completes, overload), each with a number; a cost on each decision; fewer boxes, more depth in the risky ones. So a Staff answer is shorter than a Senior one.

Next stop: A Staff deep dive: the ledger in two regions, 1 min

A Staff deep dive: the ledger in two regions

For: Staff, Principal.

Next stop: A Staff cost prompt: the bill grew 60%, 2 min

A Staff cost prompt: the bill grew 60%

For: Staff, SDE-3.

Context. Lesson 12 names four shapes of Staff situation prompt. This is the cost shape, priced from the Operate-it list.

Next stop: How a system design round is examined, 1 min

How a system design round is examined

For: SDE-1 and up.

Context. Interviewers commonly keep timestamped notes of what you asked, the numbers, what you drew and each decision with its reason, and a hiring committee reads those notes (the author's reading). In the author's estimate (not measured), at SDE-2 the design weight often falls on a machine-coding round (lesson 7), and from SDE-3 upward the high-level round weighs heavily on the level offered. Ask the recruiter which design rounds you will have.

A real round loses five to nine minutes to introductions and your questions (the author's estimate, not measured, like the minute marks). When behind, cut the API detail first, then fold the data model into labels on the diagram, then shorten the estimate. Never cut the deep dives to zero; they carry the depth evidence.

Next stop: A rubric to score your own answer, 1 min

A rubric to score your own answer

After a practice run, score each row yourself from a recording.

Next stop: Unseen prompts: a one-page method, 3 min

Unseen prompts: a one-page method

Context. Your prompt may be on no list. The method, the author's, starts from the eight you know.

1. Say "it is X, except Y" in the first five minutes. Name the nearest design aloud and the one difference that matters. "An exchange is chat's ordered log, except that the order of two messages decides who gets money."
2. Write the never-list. One or two things that must never happen. The hard part is almost always one of four hot things: a hot row (one counter many people want, Design 7), a hot key or partition (one celebrity, one symbol, Design 2), a hot connection tier (millions of open sockets, Design 4), or a hot bill (egress, SMS, model calls; Design 6's SMS line).
3. Derive the numbers; do not recall them. Put the interviewer's figures into the three formulas from the estimation section, and say the window: 86,400 seconds for a day, but a trading session or a sale is shorter.
4. Reuse boxes aloud, and spend the time on the new part. "The edge, a gateway, a queue and an outbox, as in Design 3" takes ten seconds and earns the minutes for the one part that is new.
5. When you stall, say so and go back to the never-list. "Let me step back. What must never happen is X. Design N keeps the same promise with Y. Is Y fast enough? Here is the number." The simple correct version first, then the improvement.
6. When a requirement changes, restate it and change one thing. Name the one earlier decision it breaks, change only that, recompute the one number it moves, and say what the change costs. Do not redraw the board.

Six prompts outside the eight, each taken through steps 1 and 2 (the author's selection; numbers invented):

Next stop: The pushback bank: five follow-ups for each know-cold design, 5 min

The pushback bank: five follow-ups for each know-cold design

Context. The follow-ups are the author's selection, with invented numbers. Cover the right-hand column, read a follow-up aloud, and answer before you look.

Practice with an AI: the prompt kit in the appendix has 3 cards for this lesson.

Sources