Systems

How large systems are built and hold together — the high-level end of the spectrum.

Sub-topics

• Messaging — Handing off work between services without losing it: queues, logs, and delivery guarantees.
• Search & Indexing — Finding pages and answering queries at web scale: crawling the graph politely, building the index offline, and serving prefix and keyword lookups in milliseconds.
• Feeds & Timelines — Assembling a fresh, ranked stream for every reader: fan-out on write versus on read, the celebrity hot-key, feed caches kept as ID lists, and the hydration step that turns those IDs back into posts.
• Storage — Keeping bytes safe and findable at scale: durability engines, erasure coding, replication, and the metadata that locates every object.
• Streaming — Computing over unbounded data as it arrives: stateful operators, event time and late data, consistent snapshots, and exactly-once through crashes.
• Caching — Serving reads in under a millisecond and shielding the database from the load: sharding, eviction, hot keys, and stampede protection.
• Observability — Seeing inside a running system: metrics and time-series storage, range queries and downsampling, alerting, and the cardinality that decides whether it all fits in memory.
• Orchestration — Running workflows on time and in order: DAGs of dependent tasks, cron and event triggers, retries, and crash-safe scheduling that never double-runs a job.
• Compute — Turning idle machines into elastic execution: serverless analytics, fair scheduling across tenants, and running heavy work cheaply on reclaimable spot fleets.
• Databases — Storing and querying data with real guarantees: transactions, replication, and consistency held across many machines — how a distributed SQL database keeps its promises at scale.
• Payments & Ledgers — Moving money without ever losing or duplicating a cent: the PSP boundary that keeps card numbers off your servers, idempotency against retries, the double-entry ledger that makes every movement auditable, and reconciliation against the bank.
• Geospatial — Answering "what is near me?" at scale: turning two-dimensional coordinates into one-dimensional keys a database can index, the geohash and quadtree grids, boundary-safe neighbor search, and pushing live positions to the right people as they move.
• Markets — Matching orders in microseconds: the exchange’s limit order book, the deterministic sequencer that lets a crashed engine replay its exact fills, and the single-box latency discipline that trades scale-out for a tail measured in nanoseconds.
• Media — Ingesting, transcoding, and delivering video and other heavy media at scale: parallel encode pipelines, adaptive bitrate ladders, and the CDN economics that decide what delivery costs.
• Commerce & Aggregation — Aggregating catalogs and offers across many sellers you don’t control: price and stock ingest via feeds and polite crawling, landed-cost ranking over item + shipping + tax, staleness-bounded caches, and checkout-time revalidation so the price you show survives to the charge.

Explainers

• The Audit-Proof Ledger — An auditor asks three questions a mutable database cannot answer: what was the balance last March, is this history real, and did your logic still hold after last week’s deploy? The answer is to stop storing the balance and start storing the events — every validated fact, in order, forever. Built from zero: commands versus events (intent versus recorded fact), the deterministic state machine whose replay is byte-for-byte reproducible, why the same events always yield the same balances, CQRS read models rebuilt per consumer, and the systems engineering that makes it fast (append-only files, memory-mapping, snapshots to bound replay) and reliable (a Raft-replicated event log where the leader appends and followers replay). The signature exhibit replays the same twelve-event log twice for identical balances, then corrupts one historical event and watches the divergence surface at exactly that event — computed live from a real reducer.
• Design a Trading Dashboard — A million people watching prices that move millions of times a second, and a browser that can render maybe ten of them. Built from zero: the read-side scope (the display, not the matching engine), a commit-first envelope where naively forwarding every tick is ≈240 GB/s and conflation cuts it to ≈4.8, market-data fan-in and normalization across venues, then the signature idea — conflation, keeping one latest slot per symbol and emitting ~4 times a second (exactly what Interactive Brokers ships), pub/sub fan-out over a WebSocket gateway fleet, snapshot-then-delta on subscribe with sequence-gap resync, per-client backpressure that conflates again at the socket, tiered update rates that follow attention, OHLC candle roll-ups computed on the full tick stream, portfolio P&L as the live price joined onto positions, and the two-lane guarantee split — lossy display, exact books — that runs through the whole design.
• Design a Chat System — Two people, a message, and the expectation that it arrives instantly, in order, and never vanishes — even when the recipient is in a tunnel. Built from one polling request up to a stateful WebSocket fleet over a durable inbox: the commit-first envelope that sizes everything by open connections (not requests), the honest transport fork (short poll vs long poll vs WebSocket), a session registry that finds a user across the fleet, store-then-notify with per-recipient inbox queues, Snowflake IDs because created_at collides, a bucketed key-value store for history because reads are long-tailed, the signature offline-delivery exhibit where a per-device cursor replays exactly the gap, presence via heartbeat + flap-suppression + pub/sub fanout, and a failure sweep whose surprising box is a chat server dying with all its connections.
• Design a Video Platform — Someone uploads a 4K clip; seconds later millions can stream it on a train, a laptop, a TV — and the bill to deliver it dwarfs the bill to store it. Built from zero: a commit-first envelope on the CDN egress bill (5M users × 5 plays × 300 MB is 7.5 PB a day, and the number should scare you), why one server melts, the two-lane upload with pre-signed URLs writing straight to storage and GOP-aligned resumable segments, the heart — transcoding as a DAG of tasks where every segment × resolution encodes in parallel and a dead worker costs one segment not one video, adaptive bitrate over a per-title ladder with the player choosing rung by rung, CDN economics and the long tail (cache the hot set, serve the cold tail from origin, lazily transcode what nobody watches) — then the failure sweep whose sharpest box is a poison video that turns your own idempotent retry into a fleet-killer.
• Design a Payment System — A million transactions a day is only about ten a second — so the hard part was never throughput, it was never losing or duplicating a single cent. Built from zero: the hosted-payment-page flow that keeps card numbers off your servers entirely (nonce → token → charge → webhook, with the PCI reality stated plainly), idempotency keys that survive both a double-click and a payment-processor retry, the double-entry ledger where every movement is a debit and a credit that sum to zero, why money is integers and never floats, a retry queue with a dead-letter tail for the charges that fail, and reconciliation as the last line of defense — the nightly diff against the bank’s settlement file and the three classes of mismatch it turns up. The signature exhibit sends one payment across the whole system with its idempotency key visible, replays it to watch every stage no-op, then breaks the ledger write and lets reconciliation catch the gap the next morning.
• Design an Email Service — A billion users, forty messages a day each, kept forever — email is a storage problem wearing a messaging problem’s clothes, and almost none of it is under your control once a message leaves the building. Built from zero: a commit-first envelope that lands on the yearly petabytes, the send and receive pipelines threaded through queues so a slow recipient never blocks anyone, the mailbox data model at the heart — partition by user, folders, time-ordered message IDs, and the honest read/unread denormalization a wide-column store forces on you (two tables, move the row) — the search index as its own write-heavy LSM, and deliverability as its own discipline: IP reputation, dedicated-IP warm-up, SPF/DKIM/DMARC in a breath each, and the bounce/complaint feedback loops — then the failure sweep whose sharpest box is your own IP landing on a blocklist.
• Design a Notification System — One event — “your driver is arriving” — has to reach a phone, and you own almost none of the road: the last mile belongs to Apple, Google, Twilio, and an email provider, and none of them promises the message arrives. Built from zero: a commit-first envelope on 10M push + 1M SMS + 5M email a day, why one inline sender collapses, the fan-out core where a single event lands in one queue per channel so a Twilio outage never blocks a push, the device-token table and the templates / user-settings / rate-cap layers that keep you from spamming a real person, the reliability spine (persist-then-queue, retry with backoff, and the honest at-least-once truth that dedupe reduces but cannot erase), the open/click tracking loop — then the failure sweep whose quietest box is a compliance bug that ships a notification to someone who opted out.
• Build a Report and Fan It Out to Millions — One prompt hiding two systems: a periodic batch pipeline that computes 20 million personalized reports, joined to a delivery ramp that mails every one inside a 3-hour window over a provider you don’t own. Built from zero: the scope split (compute vs deliver), a commit-first envelope where a ~2,000/s send ceiling barely clears the deadline, the naive cron loop and why it dies, the compute DAG with a pinned snapshot and per-task retries, the central precompute-vs-render-on-open deliberation tuned to the open rate, rendering to immutable artifacts behind short-lived signed links, then the delivery half — batching, a token-bucket rate shaper clamped to the provider ceiling, idempotency keys so nobody gets the report twice, suppression before the send, a checkpointed cursor so a crash resumes instead of restarting, and a live completion burn-down that proves all N went out by when. Distinct from a notification system (linked, not duplicated): this is the report COMPUTE joined to the delivery ramp.
• Design a Proximity Service — Open a maps app, tap "restaurants near me," and a few of the 200 million businesses on Earth come back in under a second. This is the retrieval shape under Yelp, "find nearby drivers," and every store locator — built from zero: why a plain index on latitude and longitude quietly falls apart, geohash derived by hand (recursive halving, prefix as zoom, base-32) with the two boundary traps that make a naive query silently miss results and the eight-neighbor fix that catches them, an honest geohash-vs-quadtree-vs-S2 deliberation, the compound-row data model, the read path and why the user’s own coordinates are a terrible cache key — then "when the points move": nearby-friends over a pub/sub channel per cell and a WebSocket fleet, honest about the write volume it costs.
• Top-K & Heavy Hitters — Who are the top ten right now? Easy at a thousand rows, brutal at a billion. Two questions wear one name: a live leaderboard of 25M players, and the heavy hitters of a firehose you can never store. Built from zero — why SQL ORDER BY dies, how a Redis sorted set answers rank in O(log n) with a skip list, how the board shards and why hashing breaks the rank query, then the streaming half: a count-min sketch that counts a billion keys in a kilobyte (and sometimes lies), a min-heap of the top ten, and lambda reconciliation when the number has to be billing-exact.
• Design a Transaction Log on Object Storage — A cloud bucket can swap one file atomically and never many at once — so how does a pile of Parquet files on S3 become an ACID table? The Delta-shaped question, built up from first principles: the naive folder and the three ways it dies, the write-ahead log as the source of truth, the put-if-absent commit (and why S3 needs a tiny coordinator), optimistic concurrency with the conflict rules raced live, checkpoints against a computed cold-read cost, compaction, time travel, and the log doubling as a message queue — then an honest Delta vs Iceberg vs Hudi.
• Design a Matching Engine — A stock exchange makes four promises at once — fairness, determinism, microsecond latency, and never losing an order — and one data structure keeps all four. Built from zero: what an exchange must guarantee, the order book as sorted price levels each holding a doubly-linked FIFO plus an id-map (place, match, and cancel all O(1), and the singly-linked trap that ruins it), a live book where you fire a market buy and watch it sweep the ask side with honest fills, the sequencer that stamps every order so the same input always replays the same fills, the single-box mmap event bus that beats the network by three orders of magnitude, hot-warm failover, and the p99 tail that a garbage-collection pause quietly ruins.
• Design a Sandboxed Code-Execution Service — Run code an LLM wrote seconds ago, for thousands of mutually suspicious tenants, without ever letting one read another’s files or take the host down — the isolation spectrum from a shared process to a hardware-walled microVM, warm pools and snapshot/restore, cgroup limits, and network policy, priced in real milliseconds and megabytes from the Firecracker and gVisor docs.
• How Google Spanner Works — A database that spans the planet and still behaves as if every transaction ran one at a time. The trick is TrueTime — a clock that answers with a range instead of an instant, so the database can wait out its own uncertainty. We walk how the data is split and copied, the waiting rule that keeps ordering honest, and when you do not need any of it — drawn, computed, and animated.
• A Write-Ahead Log You Can Implement in an Hour — The low-level-design round asks you to make a key-value store survive a crash — and the whole answer is one small file. Append a length + CRC32 framed record before you touch memory, fsync on the durability dial you choose, and on restart replay the log and drop the torn tail. We author the ~120-line Python module, crash it in a child process, and walk it top to bottom.
• Design a Stream Processor with Exactly-Once — How a system that counts events as they stream past can crash, recover, and never count anything twice: periodic snapshots of its memory, an honest way to handle events that arrive late, and an output stage that only commits when everything agrees — drawn, computed, and animated.
• Design a Distributed Cache — Start with one cache box in front of the database; end with a fleet that survives a celebrity post pulling 300k requests a second at a single key. How keys spread across machines, what gets evicted when memory fills, and the defences for when one key goes nuclear — drawn and computed.
• Design Ad-Click Aggregation (Lambda vs Kappa) — Count a billion ad clicks a day two ways at once — a dashboard fresh within seconds, and a total accurate enough to bill against. How duplicate clicks are weeded out, how late-arriving clicks are handled honestly, and why one replayable pipeline can do the work of two.
• Design a DAG Job Scheduler — A scheduler that keeps its plans in memory is a demo: the moment it crashes, jobs are lost — and running two copies for safety makes jobs run twice. Build up to schedulers that share one database safely, so no job is ever lost or double-run — drawn and animated.
• The Shuffle: How a Cluster Moves a Join — A join is trivial once the matching rows share a machine. The shuffle is the all-to-all network move that gets them there — repartition every row by a hash of its key, and everything hard follows: why it dominates query time, why one hot key strands a straggler while the fleet idles, and how adaptive splits, salting, and broadcast joins break it.
• Design a Multi-Tenant Query Engine on Object Storage — Thousands of customers, ten thousand queries at once, sub-second dashboards next to multi-hour batch jobs — all on discounted machines the cloud can take back at any moment. Split the coordinating brain from the number-crunching muscle, schedule fairly, and make a query survive its own workers being yanked mid-flight.
• Design a Durable Key-Value Store — Start with a lookup table in one server's memory; end with a storage engine that survives crashes and power loss. One idea — a log file written before anything else moves — is the whole story, drawn and computed.
• Design a Metrics & Monitoring System — Why billions of measurements a day outgrow an ordinary database and need a purpose-built one — the compression tricks that make the data fit, the label explosion that can sink the whole system, and an alerting pipeline that watches itself.
• Design S3-Like Object Storage — From one server writing files on disk to a store holding a million terabytes that survives an entire data centre dying — the bytes cut into recoverable pieces, spread across buildings, and repaired faster than they fail.
• Design Search Autocomplete — The suggestions that drop down as you type — built from zero. A trie (a tree keyed by letters) with the top few completions pre-computed and cached at every node, so a keystroke is answered by reading a list, not by searching; why a live database query per keystroke dies at ~20× the search rate; the offline pipeline that turns query logs into a fresh trie snapshot; the sub-100 ms serving path; sharding by prefix and the fix for the uneven letters; and the failure sweep whose quietest box is a trending query that stays invisible for a week.
• Design a Web Crawler — The bulk downloader behind a search engine — built from zero. Why naive breadth-first crawling is rude, and how the URL frontier makes it polite: front queues that prioritise (by PageRank, traffic, freshness) feeding back queues that enforce one host per queue, one worker, a delay between fetches. Plus robots.txt and its cache, the two dedup structures (a bloom filter of seen URLs, a hash of seen content), DNS caching and the blocking-resolver trap, spider-trap defenses, and a freshness strategy — with a live frontier you can flood from one host to watch politeness throttle it while the others proceed.
• Design a Distributed Message Queue — How services hand work to each other through a queue that never loses a message. Start with one sender and one receiver; grow it until it survives crashes and slow consumers — drawn and animated.
• Design a News Feed — Open the app and see a fresh, ranked stream of posts from everyone you follow. The whole design is one fork — do you push each post into every follower’s feed as it’s written, pull them all together at read time, or split the difference? Built from zero: a commit-first envelope on 10M users, the push/pull/hybrid deliberation with cost meters computed live, the celebrity hot-key that melts the write path, the feed cache kept as bare <post-id, user-id> lists and why not full posts, the hydration step, an honest paragraph on the ranking hand-off, and the failure sweep.
• Design a File-Sync Service — Drop a file in a folder and it appears, seconds later, on every device you own. Build the Dropbox shape from zero: cut files into content-hashed 4MB blocks so editing one block ships one block, guard a tiny metadata index with strong consistency while the bulky bytes stay loose, nudge devices with a held long-poll connection instead of a poll storm, and reconcile offline edits into first-writer-wins conflicts that never silently merge — with the delta-sync bandwidth save computed live.
• Design Google Maps — Two systems wearing the same skin: a pyramid of pre-drawn tiles you pan and zoom, and a road graph cut into tiles you route across. From the naive one-server cut to a static tile pyramid on a CDN, hierarchical routing tiles searched with a live A*, ~1M-QPS location ingestion, and live-traffic ETAs — drawn, computed, and animated.
• Design a Webhook & Trigger Delivery Platform — Thousands of customer servers, each unpredictable — slow, offline, flaky at 3am — and one bad one must never touch the rest. We compute the fan-out arithmetic (events → deliveries, retry amplification when 5% of endpoints are down, storage for a 3-day retry horizon), watch a naive POST-in-the-request-loop stall on a single slow endpoint, then build the real design one mechanism at a time: a durable queue off the request path, HMAC signature verification in both directions, per-endpoint token buckets, a jittered retry ladder to a dead-letter queue, honest at-least-once semantics, and ordering that costs only the customer who asked for it — closing on Stripe, GitHub, and Svix's own published numbers.
• Buy the Cheapest Book — It reads like a database query — sort by price, show the top row — but the two words the query hides are the whole design. “Cheapest” is never the sticker: it is a freshly-computed landed cost (item + shipping + tax, in stock, in the right condition) over prices you don’t control. And “buy” is a promise the price has to survive one click later. Built from zero: the scope dialogue that pulls both words apart, the commit-first envelope whose scary number is 11.6k external fetches a second to keep a billion offers a day fresh (which is why you don’t), the naive live-fan-out that waits on the slowest of 33 sellers and its break, the two ingest lanes (marketplace writes you own vs external feeds you crawl), tiered freshness and a crawl budget, the signature landed-cost ranking computed live where the sticker-cheapest almost never wins, a cached aggregate with a staleness clock, search over the catalog, and the load-bearing correctness beat — checkout-time price revalidation with a tolerance policy, reservation against the last-copy race, and an idempotent order that never double-charges. Grounded in Amazon’s Featured Offer and Google Merchant Center docs.