Worked documents on distributed systems: concept modules built from the ground up, pages on the technologies they name, and full designs with architecture diagrams, trade-offs and the follow-up questions that actually get asked.
Precompute or compute on demand
Do the work when data is written and reads become instant but can go stale. Do it when data is read and results stay fresh, but every request pays the cost.
Speed and availability, paid for in consistency
Replicas and caches put data closer to readers and survive failures, but every extra copy can lag behind the source of truth. The real question is how stale a read the product can tolerate.
Capacity, paid for in coordination
A bigger machine keeps everything simple until it hits a ceiling. Splitting data and traffic across machines removes the ceiling, but adds routing, rebalancing, hot keys and queries that span shards.
What you give up during a partition
When the network splits, a node either refuses requests it cannot guarantee or answers with data that may be stale. Payments and seat inventory lean correct; feeds and like counts lean available.
Spot which one a novel prompt is really about, pick a side, and defend it with the product requirement. That is the skill being tested.
Read in order. Foundations first, then the patterns everything else is built from.
Latency versus throughput, percentiles and tail amplification, scaling directions, load balancing, and estimation that ends in a decision.
Picking a database from access patterns, how indexes really cost you, replication lag, sharding strategies, and consistent hashing.
CAP stated correctly, PACELC, the consistency spectrum, quorums, Raft, idempotency, sagas, and the outbox pattern.
Cache patterns and eviction, why hit rate dominates latency, invalidation, and the three named failure modes with fixes for each.
Queues versus pub/sub, Kafka partitions and consumer groups, delivery semantics, retries with jitter, dead letter queues, CQRS and event sourcing.
Push versus pull, the read/write cost asymmetry, the celebrity problem, and the hybrid that resolves it. The most reused pattern in the field.
REST, gRPC and GraphQL compared; polling through WebSockets; cursor pagination; API gateways; and four rate limiting algorithms.
Error budgets, failover and split-brain, timeouts and circuit breakers, graceful degradation, observability, and safe schema migration.
Inverted indexes, object storage, batch versus stream processing, Bloom filters, Snowflake IDs, and geospatial indexing.
The 45-minute framework with a time budget, prompts mapped to concepts, sentences that score, what loses points, and the rubric you're graded against.
The systems you will actually name in a round. What each one is, what it is good at, and the moment it becomes the right answer.
The relational default: transactions, joins and constraints on one primary, until scale forces you off it.
Sub-millisecond memory with useful data structures: caches, counters, locks, leaderboards and rate limits.
A cache that does nothing but get and set — fewer features than Redis, and that is the argument for it.
Masterless, write-optimised storage that scales linearly — as long as every query is known in advance.
Key-value and document storage with flat latency at any size, as long as you design for the key.
An inverted index with relevance ranking — a derived view of your data, never the source of truth.
Columnar databases — ClickHouse, Druid, BigQuery — that aggregate billions of rows and cannot do point updates.
A durable, replayable, partitioned log — the backbone of nearly every asynchronous design.
Stateful computation over unbounded streams: windows, joins and aggregates that survive a crash.
S3-style storage for bytes: effectively unlimited, extremely durable, and never in the request path.
Caches near the user that cut latency, absorb read spikes, and shift most traffic off your origin.
The front door: TLS, routing, auth, rate limits and timeouts, in one place instead of every service.
Persistent connections for server push — and the stateful tier, routing and reconnect story they drag in.
Typed, binary, streaming RPC over HTTP/2 — the default for service-to-service calls behind the edge.
A small, strongly consistent store for the decisions a cluster must agree on: who leads, who is alive, who owns what.
Worked problems, ranked by how often they come up. The first five cover most of what gets asked.
A home timeline serving 150k reads per second, where one post can reach a hundred million followers.
The celebrity problem. A design that only works for the median user fails — fan-out cost is bimodal and the code path has to split.
Fifty million concurrent sockets, ordered message delivery, and users who go offline mid-conversation.
You have fifty stateful gateway nodes and a message for Alice. How does the sender find the node holding her socket, and what happens when she's offline?
A hundred million links a day and a hundred to one read skew. The classic estimation warm-up.
Generating short, unique, non-guessable keys without a central bottleneck — and recognising this is a cache problem, not a database problem.
One global limit enforced across a fleet of stateless API servers, at a million requests per second.
Enforcing a global limit without a synchronous Redis round trip on every request — and deciding what happens when the limiter's own store is down.
Events from many producers, matched to recipients, delivered in-app, by email and by push, without losing any.
Third-party delivery channels fail constantly and are rate limited. Nothing may be lost, nothing visibly duplicated, and one flaky provider must not take down the rest.
A billion documents, a hundred thousand queries a second, and autocomplete firing on every keystroke.
Search is a scatter-gather, so your latency is your slowest shard. And the index is not the source of truth — you have to explain how it stays in sync and that it lags.
Five million drivers publishing position every four seconds, matched to riders in real time.
Two problems glued together: 1.25M location writes per second that destroy any disk-backed index, and a matching step where two riders must never get the same driver.
Upload, transcode and deliver video at twenty-five terabits per second of egress.
Video bytes never touch your application servers — not on upload, not on playback. What you actually build is a metadata service and a transcoding pipeline.
Ten billion pages, ten thousand fetches a second, without hammering any single domain.
Politeness. Crawling fast is easy; crawling fast without overloading one host forces a queue design grouped by host rather than FIFO. Then dedupe at a scale where you can't store what you've seen.
Charges, captures, refunds and payouts across an unreliable external processor, with a ledger that has to balance.
The one design where consistency beats availability, and where at-least-once plus idempotent stops being a slogan and becomes the mechanism preventing double charges.
Fifty thousand people wanting the same hundred seats in the same second.
This is contention, not scale. Row lock contention breaks first, not throughput — so the answer is admission control in front of the application tier, not a bigger cluster.
Syncing files across devices without re-uploading a two gigabyte file because one paragraph changed.
Bandwidth efficiency through content-defined chunking and delta sync — plus a coherent story for two clients that edited the same file offline.
A million events a second aggregated into dashboards that are fast and billing numbers that are exact.
Event time. Clicks arrive late, out of order and duplicated. Aggregating by arrival time is easy and wrong, and advertisers are billed from these numbers.
Building Redis: a hundred nodes holding a terabyte of hot data with sub-millisecond reads.
Rebalancing. Naive modulo hashing invalidates eighty percent of the cache when you add a node and stampedes the origin. And consistent hashing does not solve hot keys.
Many people typing into one document at once, with no perceptible lag and no lost edits.
Convergence. Two users edit the same sentence with no coordination. Both must end up with an identical document and neither edit may be silently lost — so last-write-wins is catastrophically wrong.