System design interviews

Interview framework — pick a practice question and a 45- or 60-minute slot and start the clock. The interview is split into eight phases (requirements, estimates, API, data model, high-level design, deep dives, bottlenecks and trade-offs, wrap-up); the bar shows the schedule, the black line shows the time, and the tiles say how long is left in your phase and whether you are ahead or behind. Move on with Next phase (or click a phase). Each phase lists the questions to ask yourself, what you should leave it with, and the usual mistakes. Afterwards, score yourself on seven rows of a rubric and save the session; the history shows how you are improving. Mock interview: a random question picks a question for you (by theme, difficulty and style) and resets the clock. The mock interviewer panel then plays the other side: reveal the interviewer’s typical answer to each clarifying question after you have asked it aloud, and in the deep dives let it throw a curveball (“now make it multi-region”, “a celebrity posts”, “the endpoint is down for a day”) for you to answer before opening the suggested answer.

Estimator — daily active users, reads and writes per user, record and media sizes, the peak factor, replication and retention give average and peak requests per second, the read-to-write ratio, storage per day, per year and over the whole period, bandwidth in and out, a cache size (the hot share of a day’s reads), servers at 70% utilisation and shards by storage and by write rate. Show the working prints every step. Each architecture has its own preset. Below are powers of two, handy round numbers and latency numbers.

Architectures — 38 reference designs. The first fifteen: URL shortener, rate limiter, news feed, chat, notifications, search autocomplete, web crawler, distributed cache, ride-hailing, video streaming, payments, a distributed job scheduler, a metrics and logging pipeline, file sync and ticket booking. Then: likes and reactions, a leaderboard and matchmaking, photo sharing, a web-scale search engine, a recommendation system, group chat at scale, live comments, collaborative document editing, an email service, a distributed key-value store, object storage, a distributed message queue, hotel reservations, a stock exchange matching engine, proximity search, maps and routing, ad click aggregation, top-K and trending, distributed tracing, durable webhooks delivery, a unique ID generator, an online code judge, and feature flags and config. Each has the requirements, API, data model and request paths; click any box in the diagram for its role, technology options and trade-offs, and see the further reading (public papers and engineering posts) and the other tools on this site that go deeper. Deep dives has five to eight of the questions interviewers push on, with model answers to compare with your own.

Interview card (a view of every architecture) sets the design out the way an interview runs: the prompt as an interviewer would say it, the clarifying questions a strong candidate asks with the answers an interviewer typically gives, requirements, scale assumptions (with the estimator preset), an API sketch, the data model, the high-level design step by step, the deep dives the interviewer usually pushes on, follow-up curveballs with suggested answers, what separates mid-level, senior and staff answers, and common mistakes.

Simulate runs a design: requests flow through the diagram’s boxes, each with replicas, workers, a queue and a service time. Boxes turn amber and red as they get busy, and the bottleneck pulses; charts show throughput, p50 and p99 latency, queue depth and the error rate. Raise or spike the traffic, put a hot key on a shard, lose an availability zone, click a box to kill, slow, scale or re-shard it or change a cache’s hit rate, and turn on retries (with or without backoff and jitter), circuit breakers, a front-door rate limit, longer or shorter timeouts, and message queues between services. Experiments replay a design’s key lesson — a celebrity post, a cold cache, a slow payment provider, an on-sale stampede.

Question bank — every design as a question, grouped by theme (counters and social, search and discovery, messaging and real-time, storage and data infrastructure, payments and transactions, geo and maps, media, analytics and streaming, platform and infrastructure), with a difficulty (warm-up, standard, hard) and a style: product architecture rounds lean on the API, the data model and request paths; infrastructure design rounds lean on partitioning, replication, consistency and failure. Search it, filter it, start a random mock interview from the filtered list, or tick up to four designs to compare: a table of the building blocks each one uses, what they all share and what only one needs. Blocks with a runnable version open in Building blocks; Which designs use… lists the designs built on a block.

Building blocks — twelve mechanisms that come up again and again: token-bucket and sliding-window rate limiters, consistent hashing with virtual nodes, Snowflake IDs, a Bloom filter, an LRU cache, a leader lease with fencing tokens, idempotency keys, the outbox pattern, geohash, base62 short codes, and exponential backoff with jitter. Each has an explanation, its cost and pitfalls, JavaScript you can edit and run against its tests in the page, and Python, Go and Java versions to read.

Trade-offs — nine cards for the decisions interviews keep returning to: SQL or NoSQL, push or pull fan-out, strong or eventual consistency, synchronous or asynchronous, cache-aside, write-through or write-back, sharding strategies, polling, long-polling, WebSockets or SSE, monolith or microservices, and batch or stream — each option with how it works, its pros and cons and when to pick it, a rule of thumb, and what the interviewer is probing for.

Caches: a hit answers at once; a miss (or a cache that is down) makes the caller read the database — cache-aside.

Queues: with message queues on, the producer waits only for the broker to accept the message and consumers work through the backlog at their own pace (the hand-off to a consumer has no timeout); with them off, the work happens in the request.

Retries: clients retry failed requests up to the chosen count, waiting an exponential backoff (50 ms doubling, capped at 2 s), optionally with full jitter. Load balancers and gateways retry a refused connection on another replica. A load balancer takes a second to notice a dead replica; until then requests sent to it fail.

Circuit breakers open in front of a box when at least half of its last 20 or more calls in two seconds timed out, were refused or were shed by that box (failures it only passes up from further down do not count), refuse calls for three seconds, then let one probe through.

Rate limit: a token bucket at the front door rejects excess requests with a 429 at once.

Bounded queues (where a design sets one) reject work when full — load shedding.

A box is a bottleneck when it is at least 85% busy, when one of its replicas or shards is saturated, when its queue keeps growing, or when it is down.

Rates are scaled down so the simulation runs in a browser: one simulated request stands for many real ones. Service times, worker counts and replica counts are plausible but invented; use the shapes — where load piles up, how latency bends near saturation, what a failure does — not the absolute numbers.

The simulation ignores network bandwidth, CPU sharing between workers, garbage collection, connection pools, autoscaling and the cost of moving data when you re-shard (it moves instantly). Writes always go to a shard’s first live replica; reads go to the least busy one.

The estimator uses decimal units (1 KB = 1,000 bytes) and simple averages. The cache size is the classic upper bound (the hot share of a day’s reads, as if every read were a different item).

The model answers are one good way to answer, not the only one. Interviewers at different companies weight the phases differently; adjust the slot to your own interview.

The rubric is for honest self-assessment, not a hiring bar, and the level descriptions on the interview cards are a guide to depth, not any company’s levelling criteria.

The question bank lists the kind of questions commonly discussed for big-tech system design rounds; it does not claim that any company asks a particular question. Difficulty tags are a rough guide.

The compare view’s building blocks are a judgement of which mechanisms each reference design leans on; another good design for the same question may use different ones.

J. Dean, “Designs, Lessons and Advice from Building Large Distributed Systems”, LADIS 2009 keynote — the “numbers everyone should know” latency table. Powers of two and round numbers are standard arithmetic.

J. D. C. Little, “A Proof for the Queuing Formula: L = λW”, Operations Research 9(3), 1961 — checked by the engine’s tests.

M. Brooker, “Exponential Backoff and Jitter”, AWS Architecture Blog, 2015 — full jitter.

M. Fowler, “Circuit Breaker”, 2014 — the closed, open and half-open states.

D. Karger et al., “Consistent hashing and random trees”, STOC 1997 — consistent hashing.

B. H. Bloom, “Space/time trade-offs in hash coding with allowable errors”, CACM 13(7), 1970.

M. Kleppmann, “How to do distributed locking”, 2016 — fencing tokens.

G. Niemeyer, geohash (2008); the published examples ezs42 and u4pruydqqvj are used in the tests.

Twitter’s Snowflake ID layout (41-bit timestamp, 10-bit machine, 12-bit sequence), announced on the Twitter engineering blog in 2010 (the 2010 code).

Each of the later architectures lists the papers and engineering posts it draws on under Further reading in its design view. Among them: S. Brin and L. Page, “The Anatomy of a Large-Scale Hypertextual Web Search Engine”, 1998; L. A. Barroso, J. Dean and