Review Questions

About 5 minutes of introductions, 35 of design, 5 for my questions, and inside the 35 a fixed order: requirements (5), estimates (2), API (3), data model (2), high-level design (10), deep dives (10), wrap-up (3). "I aim to have a complete, working high-level design on the board by about minute 27, so the second half can go on the two hardest parts. I write the requirements and numbers down where we can both see them, and I check in with you at each phase boundary."

Learn more: A repeatable framework and What the interviewer is looking for.

The questions whose answers change the design. "Which features are in scope: upload, feed, follow, likes, comments? How many daily users, and how often does each upload and view? So what's the read/write ratio? Which paths must be fast, and how fast? How bad is downtime, and is it worse for viewing than uploading? Can a user see a slightly stale feed? Can we ever lose a photo?" Then I write down three to five core features, the numbers, and what's out of scope.

Learn more: Functional and non-functional requirements.

Because no design can fail it, so it can't be checked. A requirement needs a number and a scope: "50 M daily users at a 3× evening peak; viewing 99.99% available and uploads 99.9%; feed p99 under 300 ms; a deleted photo disappears everywhere within a minute." Now every box I draw can be tested against it, and the interviewer can see that I know which parts deserve the expensive guarantees.

Learn more: Functional and non-functional requirements and Common mistakes.

About 116 K reads a second on average and 347 K at a 3× peak, and about 14 K writes a second at peak: 25 reads per write. "So reads dominate: stateless API servers behind a load balancer, a cache in front of the database for the hot reads, and the write path is a few primary databases' worth, not a write-scaling problem."

// A social app: 200M daily users, 50 reads and 2 writes each per day, peak = 3x average.
const dau = 200e6, readsPerUser = 50, writesPerUser = 2, peakFactor = 3;
const DAY = 86_400;
const k = (n) => `${(n / 1000).toFixed(1)}K`;

const readQps = (dau * readsPerUser) / DAY;
const writeQps = (dau * writesPerUser) / DAY;
console.log(`reads:  ${k(readQps)}/s average, ${k(readQps * peakFactor)}/s peak`);
console.log(`writes: ${k(writeQps)}/s average, ${k(writeQps * peakFactor)}/s peak`);
console.log(`read:write = ${readsPerUser / writesPerUser}:1`);
// The whiteboard shortcut: a day is "about 100,000 seconds".
const shortcut = (dau * readsPerUser) / 1e5;
console.log(`shortcut reads: ${k(shortcut)}/s (${((shortcut / readQps - 1) * 100).toFixed(1)}% vs exact)`);

reads:  115.7K/s average, 347.2K/s peak
writes: 4.6K/s average, 13.9K/s peak
read:write = 25:1
shortcut reads: 100.0K/s (-13.6% vs exact)

Learn more: Back-of-the-envelope estimation.

About 1.6 TB of new messages a day, 0.58 PB a year, and about 8.8 PB over five years with three replicas. "That rules out one database server: it's a partitioned store, keyed by conversation so each chat is read from one partition, with older history possibly moved to cheaper storage."

// Chat storage: 200M daily users each send 40 messages a day, 200 bytes per message
// (text plus ids and timestamps), 3 replicas, kept 5 years. Decimal units.
const dau = 200e6, msgsPerUser = 40, bytesPerMsg = 200, replicas = 3, years = 5;
const perDay = dau * msgsPerUser * bytesPerMsg; // bytes of new messages per day, one copy
const TB = 1e12, PB = 1e15;
console.log(`messages per day: ${(dau * msgsPerUser / 1e9).toFixed(0)} billion`);
console.log(`one copy: ${(perDay / TB).toFixed(1)} TB/day, ${(perDay * 365 / PB).toFixed(2)} PB/year`);
console.log(`${years} years x ${replicas} replicas: ${(perDay * 365 * years * replicas / PB).toFixed(1)} PB`);
console.log(`write rate: ${Math.round(dau * msgsPerUser / 86_400).toLocaleString("en-US")} messages/s average`);

messages per day: 8 billion
one copy: 1.6 TB/day, 0.58 PB/year
5 years x 3 replicas: 8.8 PB
write rate: 92,593 messages/s average

Learn more: Back-of-the-envelope estimation and Partitioning and sharding strategies.

No. 17.5 GB/s is 140 Gbit/s, because network links are sold in bits and storage in bytes. "So even the average doesn't fit one 100 Gbit/s link, and the 3× peak is about 420 Gbit/s. This traffic has to come from a CDN, with object storage as its origin."

Learn more: Back-of-the-envelope estimation and CDNs.

DRAM about 100 ns, NVMe 4 KB read about 60 µs, same-zone round trip about 300 µs, zone to zone about 1–1.5 ms, US east to the UK about 78 ms. "The surprise is the middle: on modern hardware a local SSD read is faster than asking another server in the same data centre. And crossing an ocean costs about 250 times more than a round trip inside the zone (78 ms against 300 µs), which is why a request's synchronous path stays inside one region."

Learn more: Latency numbers to know.

Three round trips at about 78 ms each: one for TCP's handshake, one for TLS 1.3's, and one for the request itself. "So I keep connections open and pooled between services, terminate TLS at an edge close to users, and never put a fresh cross-region connection on a request's critical path."

Learn more: Latency numbers to know and CDNs.

99.9% allows about 43 minutes a month and 99.99% about 4.3 minutes. Redundant copies multiply their failure chances (parallel), while dependencies on the request path multiply their availabilities (serial). "Three API instances are effectively never all down, so the path is set by the single load balancer and database: about 99.94%. Adding one synchronous 99.9% dependency drops it to 99.84%, more than an hour a month, so non-critical dependencies get a fallback or move off the request path."

// A request path: load balancer -> API -> database, plus a call to a payments API.
// Availabilities per month; a 30-day month has 43,200 minutes.
const MONTH_MIN = 30 * 24 * 60;
const serial = (...parts) => parts.reduce((a, b) => a * b, 1);
const parallel = (a, n) => 1 - (1 - a) ** n; // n independent copies, any one is enough
const show = (label, a) => {
  const down = (1 - a) * MONTH_MIN;
  const text = down < 1 ? `${(down * 60).toFixed(3)} s` : `${down.toFixed(1)} min`;
  console.log(`${label.padEnd(36)}${(a * 100).toFixed(7).padStart(12)}%  ${text.padStart(9)} down/month`);
};

const lb = 0.9999, api = 0.999, db = 0.9995, payments = 0.999;
show("one API instance", api);
show("API x3 behind the LB (parallel)", parallel(api, 3));
show("LB + API x3 + DB (serial)", serial(lb, parallel(api, 3), db));
show("+ payments called synchronously", serial(lb, parallel(api, 3), db, payments));

one API instance                      99.9000000%   43.2 min down/month
API x3 behind the LB (parallel)       99.9999999%    0.003 s down/month
LB + API x3 + DB (serial)             99.9400049%   25.9 min down/month
+ payments called synchronously       99.8400649%   69.1 min down/month

Learn more: Availability, SLAs, SLOs and SLIs and Graceful degradation and fallbacks.

The SLI is the measurement, the SLO is the target you set yourself, the SLA is the contract with consequences, and the error budget is the SLO's allowed failure, spent deliberately. "For the feed, the SLI is the fraction of requests that succeed within 300 ms, the SLO is 99.9% of them over 30 days, and any SLA we sign is looser than that. The 0.1% of allowed failures is the error budget: while there's budget left we ship quickly, and when a burn-rate alert says we're spending it fast, we slow releases and fix reliability."

Learn more: Availability, SLAs, SLOs and SLIs and Observability: logs, metrics and traces.

Horizontal for the stateless tiers, from the start; vertical first for the database, for as long as it's enough. "App servers hold no state, so I put them behind a load balancer and add instances, spread over zones. The database is the hard part: I'd scale it up, move reads to replicas and caches, and only shard when the write rate or the data size forces it, because sharding costs cross-shard queries and transactions for ever."

Learn more: Vertical vs horizontal scaling and Stateless services and where the state goes.

Into shared stores built to hold it: sessions in Redis behind an opaque cookie, files in object storage via presigned uploads, durable data in the database, counters and rate limits in Redis. "The test I apply is: what breaks if the next request goes to a different instance, or this instance disappears right now? If the answer is nothing, the load balancer can use any algorithm and autoscaling can add and remove instances freely."

Learn more: Stateless services and where the state goes.

L7 at the edge for HTTP, L4 where I need raw connection throughput or non-HTTP protocols, and per-request balancing for long-lived HTTP/2 or gRPC connections. "An L7 balancer terminates TLS and sees the request, so it can route by host and path, retry idempotent requests, run canary weights and report per-route errors. An L4 balancer only sees connections, which is cheaper and protocol-agnostic, but it pins a whole HTTP/2 connection, and every request on it, to one backend."

Learn more: Load balancers: L4 vs L7.

Round robin when requests are uniform, least outstanding requests when they vary, and power of two choices when there are many balancers or the load data is stale. "Real APIs mix cheap and expensive calls, so round robin lets cheap requests queue behind expensive ones. Least outstanding requests fixes that, but many balancer nodes all seeing the same 'emptiest' server herd onto it. Picking two backends at random and sending to the less loaded one keeps most of the benefit and is robust to stale data, which is why Envoy's least-request balancer works that way by default."

Learn more: Load-balancing algorithms.

No. Losing one zone puts 105% of the load on the other two, so they fail too. "For N active copies to survive one loss, each must run below (N − 1) / N of capacity at peak: 50% for two, 67% for three, 75% for four. I'd alert on that threshold rather than on 90%, and remember that autoscaling only helps after its warm-up time."

Learn more: Redundancy, failover and single points of failure and Autoscaling.

Minutes, not seconds: health checks need about a minute and a half to agree, then resolvers keep the old answer for up to a TTL, plus a tail of clients that cache longer. "With a 60-second TTL that's two to three minutes for most users. If we need seconds, I'd put an anycast front door in front of the regions, so clients keep one stable IP and the edge switches regions itself. DNS is the coarse steering layer, not the per-request balancer."

Learn more: DNS, GeoDNS and anycast and Multi-region architecture.

Because the origin pays for misses, and the miss ratio fell from 5% to 1%: five times less origin traffic. "At 100,000 requests a second that's 5,000 a second reaching the origin versus 1,000. So normalising cache keys, adding an origin shield and using stale-while-revalidate are often worth more than adding origin servers. I'd track the origin request rate, not just the hit ratio."

Learn more: CDNs and Where to cache.

Because autoscaling the app tier multiplies connections and queries to a database that doesn't scale the same way. "Every new app instance opens its own pool, so 3× the instances can mean 3× the connections against one primary. I'd scale the stateless tier on its own saturation metric, cap the maximum to protect the database, put a connection pooler in front of it, and size the database's reads separately with replicas and caches. Autoscaling also takes minutes, so the first minutes of a spike need load shedding."

Learn more: Autoscaling and Backpressure and load shedding.

Stateless tiers and static content in every region behind a global front door; data decided per dataset. "Read-heavy data replicates to every region and each user's writes go to their home region, which also covers data-residency rules. Contended data with invariants, like inventory, has one owning region per item, or a synchronous cross-region quorum if we must lose nothing, accepting 85 ms or more per write. Counters and likes can be active-active with CRDTs. And every region keeps the headroom, or a degraded mode, to take another region's users."

Learn more: Multi-region architecture and Conflict resolution: last-write-wins and CRDTs.

Re-run the estimate at 10×, walk the diagram with the new numbers, and fix the first component that breaks, rather than listing scaling techniques. "Stateless services and the CDN scale by adding capacity, so they're not design changes. The stateful parts are: at 10× the writes the database needs partitioning, the cache cluster grows, and hot keys get worse. I'd say what I'd measure first: per-server QPS from a load test, cache hit ratio and database write latency."

Learn more: Drawing and narrating the design and Vertical vs horizontal scaling.

Say it straight away: what the flaw is, which requirement it breaks, and how you'll fix it, then change the diagram. "For example: 'The like counter is a single row, and a viral post would send thousands of updates a second to it. I'll batch the increments through the event stream and write once a second, or shard the counter and sum on read.' Finding and fixing your own mistake is what a good design review looks like, and it's stronger evidence than a design that pretends to be perfect."

Learn more: Common mistakes and Drawing and narrating the design.

Read: try the cache, on a miss read the database and set the key with a TTL. Write: update the database, then delete the key. "Deleting is safer than updating because two concurrent writers can update the cache in the opposite order to the database and leave the wrong value there for good; a delete just forces the next reader to load the current row. The TTL bounds any race I've missed, and losing a cache node costs performance, never data."

Learn more: Caching strategies and Cache invalidation and consistency.

At least 86.7%, and I'd design for well above it, because the database must also survive the cache losing a node or starting cold. "At 90% the database sees 6,000 reads a second, comfortable; at 80% it sees 12,000 and falls over. So the hit ratio isn't a nice-to-have metric here, it's a capacity dependency, and I'd add request coalescing, stale serving and load shedding so a dip doesn't become an outage."

// 60,000 reads/s reach the cache tier; the database can take 8,000 reads/s.
const reads = 60_000, dbCapacity = 8_000;
for (const hit of [0.8, 0.9, 0.95, 0.99]) {
  const toDb = reads * (1 - hit);
  const verdict = toDb <= dbCapacity ? "ok" : "overloaded";
  console.log(`hit ${String(hit * 100).padStart(2)}%: ${toDb.toLocaleString("en-US").padStart(6)} reads/s to the DB (${verdict})`);
}
// The minimum hit ratio the database can survive:
console.log(`needs at least ${((1 - dbCapacity / reads) * 100).toFixed(1)}% hits`);

hit 80%: 12,000 reads/s to the DB (overloaded)
hit 90%:  6,000 reads/s to the DB (ok)
hit 95%:  3,000 reads/s to the DB (ok)
hit 99%:    600 reads/s to the DB (ok)
needs at least 86.7% hits

Learn more: Where to cache and Distributed caches.

A cache stampede: every request that missed at the same moment went to the database for the same value. "I layer the defences: coalesce misses inside each process so one process sends one query; across the fleet, let only one request recompute, with a short lock or, better, a soft TTL that serves the stale value while one refresher updates it; refresh the hottest keys from a background job so they never expire on a request; and jitter TTLs so keys written together don't expire together."

Learn more: Hot keys and cache stampedes.

LRU by default; LFU when a stable set of popular keys is being pushed out by one-off scans, and then LFU with decay. "LRU adapts instantly when what's popular changes, but one big scan of keys read once can flush the hot set. LFU protects long-term favourites, but without decay an old favourite keeps its place for ever and new hot keys can't build up a count. Redis offers both as allkeys-lru and allkeys-lfu, and LFU there decays."

Learn more: Eviction policies: LRU, LFU and TTL.

About 91% of keys map to a different node, so the cache effectively empties and the database takes nearly the whole read load. "With consistent hashing only about 1/11 of the keys move, all of them to the new node, and with virtual nodes they come evenly from all ten old nodes. That's why caches and partitioned stores place keys on a ring or on fixed slots, never on % N."

Learn more: Consistent hashing and Resharding and hot partitions.

I decide from the access patterns and the numbers, not the label. "If the data has relations and invariants that change together, like an order, its items and the stock, I want transactions, so a relational database, and at a few thousand writes a second one primary with replicas carries it. If the access is a key or a key-plus-range at very high write rates across regions, like 70,000 messages a second read by conversation, a wide-column or key-value store partitioned on that key fits. Search goes to a search index, files to object storage."

Learn more: Choosing a database in an interview and Modelling data for access patterns.

From the hottest access pattern: the key every frequent query carries, with enough distinct values to spread load, and no single value that's hot. "For chat it's the conversation id, hashed, because every read is 'messages in conversation X' and that keeps the hot path on one shard. Queries without the key become scatter-gather or need their own index table. And huge conversations get a time bucket in the key so no partition grows for ever."

Learn more: Partitioning and sharding strategies and Secondary indexes in a sharded system.

With a global lookup table keyed by email that maps to the user id: one lookup there, then one read on the user's shard. "Asking every shard on each login would put our p90 at the mercy of the slowest shard. Signup writes the email row first with a conditional insert, which also makes emails unique across shards, then the user row. Rare admin queries like 'users created last week' can scatter-gather or go to the warehouse instead of getting their own global index."

Learn more: Secondary indexes in a sharded system.

Straight to object storage with a presigned URL; only metadata touches our database. "The API authorises the upload, creates a pending row with a key we choose, and returns a presigned PUT URL valid for a few minutes, or a URL per part for multipart uploads. The bytes never pass through our servers. An upload event goes to a queue, and a worker checks the real size and type, scans the file, makes the variants and marks the row ready. Viewers get the file through a CDN."

Learn more: Object storage for files and media.

A queue for jobs that one worker must do once; a log for business facts that several consumers need, in order per key, with replay. "Sending an email or transcoding a file is a job: competing consumers, retries, a dead-letter queue, delete on success. 'Order placed' is a fact that billing, search, analytics and fraud each need, possibly replayed to rebuild state, so it goes on a Kafka topic keyed by order id with one consumer group per service."

Learn more: Queues vs logs and Pub/sub and fan-out.

Bounded retries with exponential backoff and full jitter for transient errors, straight to a dead-letter queue for permanent ones, and to the DLQ after the last attempt either way. "That keeps the main queue moving, which for an ordered Kafka partition is essential. The DLQ keeps the original message, the error and the attempt count, alerts when it's not empty, and after a fix we redrive it at a controlled rate. All of this needs an idempotent consumer, because retries and redrives deliver the same message again."

Learn more: Retries, dead-letter queues and poison messages.

Cursor. "A feed changes while you read it, so offsets show duplicates when new posts arrive at the top and skip posts on deletes, and deep offsets get slower because the database reads and throws away every skipped row. I return { items, nextCursor }, where the cursor encodes the last item's sort key plus its id as a tie-breaker, and the query is WHERE (created_at, id) < (?, ?) ORDER BY created_at DESC, id DESC LIMIT n. Offsets are fine for small, stable admin tables that need page numbers."

Learn more: Pagination at the API level.

REST for public and partner APIs, GraphQL as the aggregation layer for many client screens, gRPC between internal services. "REST is callable by everyone, easy to rate-limit per endpoint, and its GETs are cacheable by browsers and CDNs. GraphQL gives each screen exactly the fields it needs in one round trip, at the cost of resolver batching, query cost limits and losing simple HTTP caching. gRPC gives a strict contract, compact Protobuf and deadlines that propagate, but it isn't browser-native, so it stays behind the gateway."

Learn more: REST vs GraphQL vs gRPC and Reverse proxies and API gateways.

SSE. "Updates only flow from server to client, so I don't need WebSockets. Polling every 5 seconds would be 200,000 requests a second with only about one in six finding anything new, and it adds 2.5 seconds of delay on average. SSE holds a million connections instead, a handful of servers, and pushes each update once; EventSource reconnects by itself and sends Last-Event-ID so the server can replay what was missed. I'd serve it over HTTP/2 and send a heartbeat comment every 30 seconds."

// 1,000,000 viewers on a live-score page. Option 1: poll every 5 s. Option 2: SSE, 1 update every 30 s.
const viewers = 1_000_000;
const pollEvery = 5, updateEvery = 30;
const pollRps = viewers / pollEvery;
const useful = (1 / updateEvery) / (1 / pollEvery); // fraction of polls that find something new
console.log(`polling: ${pollRps.toLocaleString("en-US")} requests/s, ${(useful * 100).toFixed(0)}% of them useful`);
console.log(`polling: average extra delay ${pollEvery / 2} s, worst ${pollEvery} s`);
console.log(`SSE: ${viewers.toLocaleString("en-US")} open connections, ${(viewers / updateEvery).toLocaleString("en-US", { maximumFractionDigits: 0 })} messages/s pushed`);
console.log(`SSE at 200,000 connections per server: ${Math.ceil(viewers / 200_000)} servers (+1 spare)`);

polling: 200,000 requests/s, 17% of them useful
polling: average extra delay 2.5 s, worst 5 s
SSE: 1,000,000 open connections, 33,333 messages/s pushed
SSE at 200,000 connections per server: 5 servers (+1 spare)

Learn more: Real-time options: polling, long polling, SSE, WebSockets and Scaling WebSockets.

Through a pub/sub backplane: thin gateway servers hold the sockets and subscribe only to the channels their users are in; the chat service persists the message with a sequence number, then publishes it. "The backplane is at-most-once, so a client that was disconnected catches up from the store by sending its last sequence number. Presence is a heartbeat key with a TTL. I cap connections per gateway to limit the blast radius, and clients reconnect with jittered backoff so a failed gateway's users don't all reconnect at once."

Learn more: Scaling WebSockets and Design a chat system.

A token bucket per API key, in Redis, updated atomically by a small Lua script. "Capacity sets the allowed burst and the refill rate the sustained limit, which matches how clients behave: a page load fires several calls, then nothing. It's two numbers per key. I'd remember that a bucket allows up to capacity plus rate × T in any span T. For daily quotas I'd add a window counter, for logins a sliding log because the limits are tiny and exactness matters, and rejections return 429 with Retry-After."

Learn more: Rate limiting algorithms and Design a rate limiter.

With an idempotency key: the client generates one per intended payment and sends it on every retry; the server claims it atomically before doing any work and stores the response under it. "A retry with the same key and body gets the stored response; a duplicate that arrives while the first is still running gets 409; the same key with a different body gets 422. The key is passed on to the card processor too, so a crash between charging and recording can't charge twice."

Learn more: Idempotency keys for APIs and Design a payment system.

UUID v7 for most services, Snowflake when I need 64-bit keys, and UUID v4 only where ids must be unguessable and aren't clustered keys. "v7 is time-ordered, so inserts append to the right edge of the index instead of touching random pages, needs no coordination, and is built into PostgreSQL 18. Snowflake packs 41 bits of milliseconds, 10 bits of worker and 12 bits of sequence into 64 bits; the two things to get right are unique worker ids and the clock going backwards."

// How long does a Snowflake's 41-bit millisecond timestamp last, and how many IDs per worker?
const span = 2 ** 41; // milliseconds
console.log(`41 bits of ms: ${(span / 1000 / 86_400 / 365.25).toFixed(1)} years from the custom epoch`);
const twitterEpoch = 1288834974657; // 2010-11-04, Twitter's published Snowflake epoch
console.log(`Twitter's epoch runs out on ${new Date(twitterEpoch + span).toISOString().slice(0, 10)}`);
console.log(`12-bit sequence: ${2 ** 12} IDs per ms per worker = ${(2 ** 12 * 1000).toLocaleString("en-US")}/s`);
console.log(`10-bit worker id: ${2 ** 10} workers`);

41 bits of ms: 69.7 years from the custom epoch
Twitter's epoch runs out on 2080-07-10
12-bit sequence: 4096 IDs per ms per worker = 4,096,000/s
10-bit worker id: 1024 workers

Learn more: Unique ID generation.

Seven base62 characters from a counter: 365 billion codes fit in 3.52 trillion, about 10% used. "Six characters hold only 56.8 billion. I'd generate from a counter handed out in ranges, scrambled with a keyed permutation so codes aren't enumerable, because random codes would need a uniqueness check and retries, and by the end about one insert in ten would clash."

// How many base62 characters for 100M new codes a day, for 10 years, from a counter?
const total = 100e6 * 365 * 10;
let len = 1;
while (62 ** len < total) len++;
console.log(`codes needed: ${(total / 1e9).toFixed(0)} billion`);
console.log(`${len - 1} chars: ${(62 ** (len - 1) / 1e9).toFixed(1)} billion (too few)`);
console.log(`${len} chars: ${(62 ** len / 1e12).toFixed(2)} trillion, ${((total / 62 ** len) * 100).toFixed(1)}% used`);
// Random codes instead: chance that a new code clashes when the table is that full.
console.log(`random codes at the end: 1 insert in ${Math.round(62 ** len / total)} clashes`);

codes needed: 365 billion
6 chars: 56.8 billion (too few)
7 chars: 3.52 trillion, 10.4% used
random codes at the end: 1 insert in 10 clashes

Learn more: Base62 and short codes and Design a URL shortener.

About 1.1 GiB for a 1% false-positive rate, against about 75 GiB to store the URLs themselves. "A Bloom filter never says 'no' wrongly, so a 'not seen' answer is final and needs no further lookup; a 'maybe' goes to the real URL store. Each extra 10× in accuracy costs about 4.8 more bits per item. The costs: I can't delete, I must size it up front, and every 'maybe' still needs the real check."

// Sizing a Bloom filter: n items, target false-positive rate p.
// Optimal bits m = -n ln p / (ln 2)^2, optimal hash count k = (m / n) ln 2.
const size = (n, p) => {
  const m = Math.ceil((-n * Math.log(p)) / Math.LN2 ** 2);
  const k = Math.round((m / n) * Math.LN2);
  return { bitsPerItem: m / n, k, gib: m / 8 / 2 ** 30 };
};
for (const p of [0.01, 0.001]) {
  const { bitsPerItem, k, gib } = size(1e9, p);
  console.log(`1B items at ${p * 100}%: ${bitsPerItem.toFixed(2)} bits/item, k = ${k}, ${gib.toFixed(2)} GiB`);
}
// Compare: storing the items themselves, 1B URLs averaging 80 bytes.
console.log(`exact set of URLs: ${(1e9 * 80 / 2 ** 30).toFixed(1)} GiB before any index overhead`);

1B items at 1%: 9.59 bits/item, k = 7, 1.12 GiB
1B items at 0.1%: 14.38 bits/item, k = 10, 1.67 GiB
exact set of URLs: 74.5 GiB before any index overhead

Learn more: Bloom filters and Design a web crawler.

HyperLogLog for counting distinct things, count-min sketch for how often each thing occurs. "Unique visitors per page per day is a cardinality question: a HyperLogLog is at most 12 KB with about 0.8% error, and weekly uniques come from merging daily sketches. Trending queries or top pages are a frequency question: a count-min sketch with a small heap for the top k, accurate for heavy hitters and useless for rare items, which is the right way round for 'trending'. Neither is for billing."

Learn more: HyperLogLog and count-min sketch.

Pick the precision whose cells are at least the radius (length 6, about 1.2 × 0.6 km at the equator), query that cell plus its 8 neighbours, then filter by real distance and rank. "The bug is searching only the user's own cell: two points a metre apart across a cell edge can share no prefix at all, so the nearest place can be in a neighbouring cell. For uneven density I'd use a quadtree that splits at about 100 places per leaf."

Learn more: Geohashing and quadtrees and Design nearby places search.

Verify, dedupe, enqueue, answer 2xx quickly; do the work later from our own queue. "The endpoint reads the raw body, checks the HMAC signature in constant time and the timestamp within about five minutes, inserts the event id with a unique constraint, puts the event on our queue and returns. A worker processes it idempotently and never lets an older event overwrite newer state. Because providers deliver at least once, out of order, and eventually give up, a reconciliation job lists recent objects through their API and fills gaps."

Learn more: Webhooks.

A can't know: a lost request, a lost reply and a slow server all look the same from A's side. "So I give every call a timeout, retry only with backoff and jitter and only if the operation is idempotent (with an idempotency key if it isn't naturally), put a circuit breaker in front of B so a slow B doesn't take A down, and where the outcome matters, like a payment, I query B for the result by the key instead of guessing."

Learn more: Why distributed systems are hard and Idempotency and exactly-once.

Different parts choose differently, and I'd say which and why. "Booking a seat is CP: the inventory has one primary with majority writes, and if a region can't reach it, booking there fails with a retry message rather than risking a double booking. Browsing, search and the 'interested' counter are AP: served from regional replicas and caches that may be slightly stale. And PACELC adds the normal case: without a partition the CP part costs a few milliseconds per write for replication across zones, which is why I don't replicate it synchronously across regions."

Learn more: CAP and PACELC in a design discussion.

The write went to the primary and the refresh was served by a replica that hadn't applied it yet: a read-your-writes violation caused by normal replication lag. "The simplest fix is to read the user's own profile from the primary for a short window after they write it. Better: the write returns a version or log position, the session keeps it, and reads go to a replica that has reached that position or fall back to the primary. Other users' profiles can still come from any replica."

Learn more: Consistency models and Replication: leader-follower, multi-leader and leaderless.

N from durability and failure domains, then R and W from the read/write mix and the freshness the feature needs. "Three replicas in three zones survives a zone outage. For reads that must see the latest acknowledged write I need R + W > N, so with N = 3 it's 2 and 2: both reads and writes survive one replica down. If stale reads are fine, W = 1, R = 1 is the fastest and most available. And R + W > N gives fresh reads, not linearizability."

// For N replicas, which (R, W) give fresh reads (R + W > N), and how many replica
// failures can reads and writes each survive?
for (const N of [3, 5]) {
  console.log(`N = ${N}`);
  for (let W = 1; W <= N; W++) {
    for (let R = 1; R <= N; R++) {
      if (R + W !== N + 1 && !(R === 1 && W === 1)) continue; // the useful edge cases
      const fresh = R + W > N ? "fresh" : "may be stale";
      console.log(`  W=${W} R=${R}: ${fresh.padEnd(13)} writes survive ${N - W} down, reads survive ${N - R} down`);
    }
  }
}

N = 3
  W=1 R=1: may be stale  writes survive 2 down, reads survive 2 down
  W=1 R=3: fresh         writes survive 2 down, reads survive 0 down
  W=2 R=2: fresh         writes survive 1 down, reads survive 1 down
  W=3 R=1: fresh         writes survive 0 down, reads survive 2 down
N = 5
  W=1 R=1: may be stale  writes survive 4 down, reads survive 4 down
  W=1 R=5: fresh         writes survive 4 down, reads survive 0 down
  W=2 R=4: fresh         writes survive 3 down, reads survive 1 down
  W=3 R=3: fresh         writes survive 2 down, reads survive 2 down
  W=4 R=2: fresh         writes survive 1 down, reads survive 3 down
  W=5 R=1: fresh         writes survive 0 down, reads survive 4 down

Learn more: Quorums: R + W > N and Design a distributed key-value store.

Because the servers' clocks disagree and can jump, so a write that really happened later can carry an earlier timestamp and be silently overwritten under last-write-wins. "If I only need a total order that respects causality, Lamport clocks give one. If I need to know whether two writes conflicted, I need version vectors: they tell me whether one write had seen the other or whether they were concurrent, and concurrent writes go to a merge rule instead of a coin flip on clock skew."

// Compare version vectors: before, after, equal, or concurrent?
function compare(a, b) {
  const ids = new Set([...Object.keys(a), ...Object.keys(b)]);
  let aBigger = false, bBigger = false;
  for (const id of ids) {
    const x = a[id] ?? 0, y = b[id] ?? 0;
    if (x > y) aBigger = true;
    if (y > x) bBigger = true;
  }
  if (aBigger && bBigger) return "concurrent";
  if (aBigger) return "a after b";
  if (bBigger) return "a before b";
  return "equal";
}
const cases = [
  [{ A: 1 }, { A: 2 }],
  [{ A: 2, B: 1 }, { A: 2 }],
  [{ A: 2 }, { B: 1 }],
  [{ A: 3, B: 1 }, { A: 2, B: 2 }],
];
for (const [a, b] of cases) console.log(`${JSON.stringify(a)} vs ${JSON.stringify(b)}: ${compare(a, b)}`);

{"A":1} vs {"A":2}: a before b
{"A":2,"B":1} vs {"A":2}: a after b
{"A":2} vs {"B":1}: concurrent
{"A":3,"B":1} vs {"A":2,"B":2}: concurrent

Learn more: Time and ordering: Lamport and vector clocks.

Because a majority of 4 is 3, so 4 nodes survive only one failure, the same as 3, while costing more and splitting worse. "Three nodes tolerate one failure, five tolerate two. An even number adds a machine that can fail and makes every write wait for one more acknowledgement, and a 2 + 2 network split leaves neither side with a majority, so the whole cluster stops."

// Consensus cluster sizes: votes needed for a majority, and failures tolerated.
for (let n = 1; n <= 7; n++) {
  const majority = Math.floor(n / 2) + 1;
  console.log(`${n} node${n > 1 ? "s" : " "}: majority ${majority}, tolerates ${n - majority} down`);
}

1 node : majority 1, tolerates 0 down
2 nodes: majority 2, tolerates 0 down
3 nodes: majority 2, tolerates 1 down
4 nodes: majority 3, tolerates 1 down
5 nodes: majority 3, tolerates 2 down
6 nodes: majority 4, tolerates 2 down
7 nodes: majority 4, tolerates 3 down

Learn more: Leader election and consensus.

Take a lease on a key in etcd or ZooKeeper, keep renewing it, and attach a fencing token, the lease revision, to everything the leader does. "If the leader dies or is partitioned away, the lease expires and another instance wins. Split brain can still happen if the old leader is paused, say by GC, and doesn't notice its lease has gone, so the downstream system rejects any token older than the newest it has seen. A lock without fencing is only a hint."

Learn more: Leader election and consensus and Design a distributed job scheduler.

A saga, not two-phase commit: a sequence of local transactions with a compensation for each step, run by an orchestrator. "The order is created as PENDING, stock is reserved, payment is authorised, then captured, and the order is CONFIRMED. If a step fails, the compensations run backwards: void the authorisation, release the reservation, cancel the order. Each step is idempotent, keyed by order id and step, because the orchestrator retries, and every service publishes its events through an outbox."

Learn more: Distributed transactions: two-phase commit, sagas and the outbox.

The dual write: updating the database and publishing an event as two separate steps means a crash between them either loses the event or publishes one for a change that rolled back. "With an outbox, the service writes the business row and an event row in the same local transaction. A relay reads the outbox table, or the database's change log, and publishes to the broker, retrying until it succeeds. Delivery becomes at-least-once, so consumers dedupe on the event id."

Learn more: Distributed transactions: two-phase commit, sagas and the outbox and Pub/sub and fan-out.

Not exactly-once delivery, no; what I build is at-least-once delivery plus idempotent effects, which gives exactly-once results. "Each message carries an id generated once by the producer. The consumer, in one database transaction, inserts that id into a processed-events table with a unique constraint and applies the effect; a redelivery hits the constraint and is skipped. For external calls I pass the message id as the idempotency key. Kafka-to-Kafka pipelines can use transactions to commit output and offsets atomically."

Learn more: Idempotency and exactly-once and Delivery guarantees and ordering.

A PN-counter CRDT per post: one increment and one decrement slot per region, merged by taking the maximum of each slot. "Each region only updates its own slots and ships its state to the others asynchronously; the merge is commutative, associative and idempotent, so order and duplicates don't matter, and the count is the sum. Last-write-wins on a plain number would lose concurrent increments. The like itself is a unique (user, post) row, so nobody likes twice."

Learn more: Conflict resolution: last-write-wins and CRDTs and Design a collaborative document editor.

Timeouts with deadlines, retries at one layer with a budget, a circuit breaker per dependency, and a bulkhead per dependency sized with Little's law. "Each call's timeout sits just above the callee's p99, and the request carries a deadline so no hop keeps working after the user has gone. Retries are only for transient errors on idempotent calls, with full jitter and a budget of about 10% of traffic. The breaker opens on an error rate and fails fast to a fallback, and each dependency gets its own pool of slots so a hung one can only exhaust its own."

// Little's law: requests in flight = arrival rate x time each one takes.
// Size a connection pool (bulkhead) per dependency from its peak rate and p99 latency.
const deps = [
  { name: "payments", rps: 400, p99: 0.8 },
  { name: "inventory", rps: 1_500, p99: 0.05 },
  { name: "recommendations", rps: 2_000, p99: 0.3 },
];
const headroom = 1.5;
const pools = {};
for (const d of deps) {
  const inFlight = d.rps * d.p99;
  pools[d.name] = Math.ceil(inFlight * headroom);
  console.log(`${d.name.padEnd(16)} ${String(inFlight).padStart(4)} in flight at p99 -> pool of ${pools[d.name]}`);
}
// Recommendations slows to 5 s per call. How many slots would it need now?
const needed = 2_000 * 5;
console.log(`recommendations at 5 s needs ${needed.toLocaleString("en-US")} slots; ` +
  `its pool of ${pools.recommendations} fills and ${((1 - pools.recommendations / needed) * 100).toFixed(0)}% of calls fail fast`);

payments          320 in flight at p99 -> pool of 480
inventory          75 in flight at p99 -> pool of 113
recommendations   600 in flight at p99 -> pool of 900
recommendations at 5 s needs 10,000 slots; its pool of 900 fills and 91% of calls fail fast

Learn more: Timeouts, retries, circuit breakers and bulkheads.

The page still renders; the recommendations slot falls back to a cached, non-personalised list, or disappears. "Recommendations is non-critical, so it has a short timeout, a circuit breaker, and a fallback of bestsellers in the category refreshed hourly. Pricing is critical: if it's down we don't show a stale price, we show 'temporarily unavailable' on the buy button, because a wrong price is worse than none. Under overload, requests carry a criticality and recommendations is shed first so checkout keeps working."

Learn more: Graceful degradation and fallbacks.

Cells and shuffle sharding: split customers into independent copies of the stack, and deploy cell by cell. "Each cell is a full stack behind a thin router keyed by tenant id, so a bad deploy, a poison request or an overloaded database hits one cell's customers, not everyone. Where customers share a pool of workers, shuffle sharding gives each one a random subset, so a customer that crashes every worker it touches takes down almost nobody else."

Learn more: Failure modes and blast radius.

Page on symptoms users feel, SLO burn rate on errors and latency at the edge; put causes like CPU, queue depth and restarts on dashboards. "Every service emits RED metrics per endpoint (rate, errors, duration as a histogram), USE metrics for resources, traces propagated with W3C traceparent through HTTP and message headers, and structured logs with the trace id. Alerts use multiwindow burn rates, and percentiles come from merged histograms, never from averaging each host's p99."

Learn more: Observability: logs, metrics and traces.

Canary for most releases, blue-green when I need an instant, whole-fleet switch, and feature flags to separate deploying code from releasing features. "A canary sends 1–5% of traffic to the new version next to a fresh baseline, compares errors and latency automatically, then widens in steps, cell by cell or region by region. Blue-green keeps a whole second environment and flips traffic at once, so rollback is fast but a bad change hits everyone the moment you flip. Either way, schema changes use expand and contract so any deploy can be rolled back."

Learn more: Deployments: blue-green, canary and feature flags.

No. Restoring 10 TB takes hours, so the RTO needs a standby replica in another region that can be promoted; backups are still needed for a different failure. "RPO is how much data we may lose, RTO how long we may be down. Continuous replication gives an RPO of seconds and promotion takes minutes. But replication copies bad writes too, so I keep point-in-time recovery, nightly snapshots plus continuously shipped WAL, in a separate account with object lock, and I test restores to know the real RTO."

Learn more: Disaster recovery: RPO, RTO and backups.

Walk the request path and name the check at each boundary. "At the edge: CDN with DDoS absorption and WAF, TLS 1.3, origin reachable only through the edge. At the gateway: authentication with short-lived tokens, rate limits, request size limits. In each service: authorisation against the specific object, tenant first and deny by default, because a valid token says nothing about which order you may read. Between services: mTLS and least-privilege identities. Data encrypted at rest with KMS keys, secrets in a secrets manager, and an audit log of privileged actions."

Learn more: Security in a design review and Frontend security.

A URL shortener whose values are too big for the hot store: short codes from a counter, the text in object storage, metadata in a database, and a CDN in front of reads. "At 2 million pastes a day it's about 70 writes and 700 reads a second at peak, and about 27 TB of text over five years. So the code generator is the URL shortener's (counter ranges, base62, scrambled), the metadata row holds the code, owner, size, expiry and the object key, and the content goes to object storage under that key, written before the row so a link never points at nothing. Reads go GET /p/{code} → CDN → service → object storage, with long cache TTLs because a paste never changes after creation; expiry is checked on read and a lifecycle job deletes expired objects."

// Pastebin. Assumptions: 2M new pastes a day, 10 KB average, 10 reads per paste,
// peak 3x, keep 5 years, 1 in 4 pastes expires within a month (not counted in storage).
const DAY = 86_400, perDay = 2e6, size = 10e3, readsPer = 10, peak = 3, years = 5;
const kept = perDay * 0.75;
console.log(`writes: ${(perDay / DAY).toFixed(0)}/s avg, ${(perDay / DAY * peak).toFixed(0)}/s peak`);
console.log(`reads:  ${(perDay * readsPer / DAY).toFixed(0)}/s avg, ${(perDay * readsPer / DAY * peak).toFixed(0)}/s peak`);
console.log(`content: ${(kept * size * 365 * years / 1e12).toFixed(1)} TB in ${years} years (object storage)`);
console.log(`metadata at 200 B/paste: ${(kept * 200 * 365 * years / 1e12).toFixed(2)} TB (database)`);

writes: 23/s avg, 69/s peak
reads:  231/s avg, 694/s peak
content: 27.4 TB in 5 years (object storage)
metadata at 200 B/paste: 0.55 TB (database)

Learn more: Design a URL shortener, Object storage for files and media and CDNs.

Keep analytics off the redirect path: the redirect publishes a click event and answers; a stream job aggregates; an OLAP store serves the owner's dashboard. "At chapter 10's scale that's about 11,600 clicks a second on average and 35,000 at peak, 300 GB of raw events a day. The redirect service fires an event (code, time, referrer, country from the IP, user agent) to a Kafka topic partitioned by code, without waiting. A stream job keeps per-code counters and flushes rollups every minute: clicks per code per minute and per day by country and referrer, plus a HyperLogLog per code per day for unique visitors. Raw events go to object storage for reprocessing. The dashboard reads the rollups from a columnar store such as ClickHouse or Druid."

// Click analytics for a URL shortener: 1 billion redirects a day (chapter 10's 11,574/s average),
// 300-byte click events, peak 3x. Rollups per (code, minute) and per (code, day, country).
const clicks = 1e9, eventBytes = 300, peak = 3;
const perSec = clicks / 86_400;
console.log(`events: ${Math.round(perSec).toLocaleString("en-US")}/s avg, ${Math.round(perSec * peak).toLocaleString("en-US")}/s peak`);
console.log(`raw log: ${(clicks * eventBytes / 1e9).toFixed(0)} GB/day, ${(clicks * eventBytes * 365 / 1e12).toFixed(0)} TB/year before compression`);
// Assume 20M distinct codes get at least one click per day, each clicked in 5 distinct minutes
// and from 3 countries on average.
const activeCodes = 20e6;
console.log(`minute rollup rows/day: ${(activeCodes * 5 / 1e6).toFixed(0)}M; country-day rows: ${(activeCodes * 3 / 1e6).toFixed(0)}M`);
console.log(`unique visitors: HLL per code per day, ${(activeCodes * 1.5e3 / 1e9).toFixed(0)} GB at ~1.5 KB each (sparse)`);

events: 11,574/s avg, 34,722/s peak
raw log: 300 GB/day, 110 TB/year before compression
minute rollup rows/day: 100M; country-day rows: 60M
unique visitors: HLL per code per day, 30 GB at ~1.5 KB each (sparse)

Learn more: Design a URL shortener, Batch vs stream processing and HyperLogLog and count-min sketch.

The photo app from chapter 1 at ten times the users, plus the news feed from chapter 11: presigned uploads to object storage, asynchronous resizing, a CDN for every image, and a hybrid fan-out feed of post ids. "At 500 M daily users it's about 1,700 uploads, 174 K feed loads and 1.7 M image views a second at peak, 120 TB of new media a day and about 4.2 Tbit/s of image egress, so images can only come from a CDN. Upload: the client gets a presigned URL, sends the bytes to object storage, and a worker makes the sizes and formats and marks the post ready. Feed: on post, a fan-out service pushes the post id into each follower's cached timeline, except for accounts above a follower threshold, which are merged at read time. Reads hydrate ids from caches of posts and users. Likes and comments are counted asynchronously."

// Instagram-scale photo sharing: chapter 1's photo-app ratios at 10x the users (assumption: 500M DAU).
// Per user per day: 0.1 uploads (2.4 MB stored with resized copies), 10 feed loads (20 KB), 100 photo views (300 KB).
const dau = 500e6, DAY = 86_400, peak = 3;
const qps = (perUser) => (dau * perUser) / DAY;
const f = (n) => (n >= 1e6 ? `${(n / 1e6).toFixed(2)}M` : n >= 1e3 ? `${(n / 1e3).toFixed(1)}K` : `${Math.round(n)}`);
console.log(`uploads: ${f(qps(0.1))}/s avg, ${f(qps(0.1) * peak)}/s peak`);
console.log(`feed loads: ${f(qps(10))}/s avg, ${f(qps(10) * peak)}/s peak`);
console.log(`photo views: ${f(qps(100))}/s avg, ${f(qps(100) * peak)}/s peak`);
console.log(`new media: ${(dau * 0.1 * 2.4e6 / 1e12).toFixed(0)} TB/day, ${(dau * 0.1 * 2.4e6 * 365 / 1e15).toFixed(1)} PB/year`);
console.log(`image egress at peak: ${(qps(100) * peak * 300e3 * 8 / 1e12).toFixed(1)} Tbit/s (CDN)`);

uploads: 579/s avg, 1.7K/s peak
feed loads: 57.9K/s avg, 173.6K/s peak
photo views: 578.7K/s avg, 1.74M/s peak
new media: 120 TB/day, 43.8 PB/year
image egress at peak: 4.2 Tbit/s (CDN)

Learn more: Back-of-the-envelope estimation, Design a news feed and Design a comments and likes system.

Pre-render the low zooms, render the high zooms on demand and cache them, and let a CDN serve almost everything, because tiles are immutable per map version. "The world is a pyramid: zoom z has 4^z tiles of 256 × 256 pixels, so zoom 18 alone is 69 billion tiles and three quarters of all tiles up to it. Most of those are ocean or empty and can share one blank tile, and most of the rest are never requested. So zooms 0 to about 12 are rendered ahead of time, deeper tiles are rendered on first request and stored in object storage, and every tile URL contains the map version, /v42/{z}/{x}/{y}, so the CDN caches it for ever and a new map version is a new set of URLs. Modern clients fetch vector tiles and draw them on the GPU, which makes one tile serve every style, rotation and label language."

// Map tiles: zoom z has 4^z tiles of 256x256 px. How many tiles to pre-render, and how big?
// Assumptions: 15 KB per raster tile on average; ~70% of tiles at high zoom are ocean or empty
// and are served from one shared "blank" tile instead of being stored.
const avgKB = 15, emptyShare = 0.7;
let total = 0;
for (const z of [0, 5, 10, 15, 18, 20]) console.log(`zoom ${String(z).padStart(2)}: ${(4 ** z).toLocaleString("en-US")} tile${z ? "s" : ""}`);
for (let z = 0; z <= 18; z++) total += 4 ** z;
console.log(`zoom 0-18: ${(total / 1e9).toFixed(1)} billion tiles`);
const stored = total * (1 - emptyShare);
console.log(`stored after dropping empty tiles: ${(stored / 1e9).toFixed(1)} billion, ${(stored * avgKB * 1e3 / 1e15).toFixed(2)} PB`);
console.log(`share of all tiles at zoom 18 alone: ${((4 ** 18 / total) * 100).toFixed(0)}%`);

zoom  0: 1 tile
zoom  5: 1,024 tiles
zoom 10: 1,048,576 tiles
zoom 15: 1,073,741,824 tiles
zoom 18: 68,719,476,736 tiles
zoom 20: 1,099,511,627,776 tiles
zoom 0-18: 91.6 billion tiles
stored after dropping empty tiles: 27.5 billion, 0.41 PB
share of all tiles at zoom 18 alone: 75%

Learn more: CDNs, Object storage for files and media and Geohashing and quadtrees.

Agents push samples (or scrapers pull them) into a sharded time-series store, recent data stays at full resolution, old data is rolled up, and alerting runs as its own always-on evaluator. "With 20,000 hosts and 500 series each, that's 10 million active series and about 670,000 samples a second at a 15-second interval. A TSDB compresses each sample to 1–2 bytes (the Prometheus documentation's figure), so raw data is about 86 GB a day: 15 days at full resolution, then 5-minute rollups of count, sum, min and max kept for 13 months. Ingest is sharded by series hash, each shard replicated; queries fan out to the shards and merge. Alert rules are evaluated every 15–60 seconds by a separate service that reads recent data from memory, so alerting keeps working when dashboards are slow."

// A metrics system. Assumptions: 20,000 hosts x 500 active series each, scraped every 15 s,
// 1.5 bytes per stored sample (Prometheus documents 1-2 bytes), raw kept 15 days,
// then 5-minute rollups (count, sum, min, max: ~4 values) kept 13 months.
const series = 20_000 * 500, interval = 15, bytes = 1.5;
const samplesPerSec = series / interval;
const perDay = samplesPerSec * 86_400 * bytes;
console.log(`active series: ${(series / 1e6).toFixed(0)}M, ingest ${Math.round(samplesPerSec).toLocaleString("en-US")} samples/s`);
console.log(`raw: ${(perDay / 1e9).toFixed(0)} GB/day, ${(perDay * 15 / 1e12).toFixed(1)} TB for 15 days`);
const rollupPerDay = series * (86_400 / 300) * 4 * bytes;
console.log(`5-min rollups: ${(rollupPerDay / 1e9).toFixed(1)} GB/day, ${(rollupPerDay * 395 / 1e12).toFixed(1)} TB for 13 months`);
// A dashboard panel for one metric over 7 days across 10,000 series at 15 s resolution:
console.log(`naive 7-day panel over 10,000 series: ${(10_000 * 7 * 86_400 / 15 / 1e6).toFixed(0)}M samples to read`);

active series: 10M, ingest 666,667 samples/s
raw: 86 GB/day, 1.3 TB for 15 days
5-min rollups: 17.3 GB/day, 6.8 TB for 13 months
naive 7-day panel over 10,000 series: 403M samples to read

Learn more: Time-series, wide-column and graph stores and Observability: logs, metrics and traces.

Inbound SMTP servers behind MX records accept mail, a pipeline filters and classifies it, messages land in per-mailbox storage with bodies in blob storage and metadata in a partitioned store, a per-user search index serves search, and clients sync by change log. "With an assumed 1 billion mailboxes receiving 40 messages a day, that's 40 billion messages a day, about 460,000 a second, and around 2.8 PB of new storage a day even after storing shared attachments once. So the mailbox is partitioned by user id: metadata (labels, read state, thread id) in a wide-column or sharded relational store, bodies and attachments in blob storage, content-addressed so one attachment sent to a thousand people is stored once. Search is a per-user inverted index updated asynchronously. Sending goes through an outbound queue to MTAs that sign with DKIM, retry with backoff for days, and handle bounces."

// A Gmail-style mailbox service. Assumptions: 1 billion mailboxes, 40 messages received per day each,
// 50 KB average message (bodies small, attachments dominate), 30% of bytes are attachments shared
// by many recipients (stored once, so counted as ~0 per recipient), 2 copies in two regions.
const users = 1e9, perUser = 40, avg = 50e3, dedupedShare = 0.3, copies = 2;
const msgs = users * perUser;
const bytes = msgs * avg * (1 - dedupedShare) * copies;
console.log(`incoming: ${(msgs / 1e9).toFixed(0)} billion messages/day = ${Math.round(msgs / 86_400).toLocaleString("en-US")}/s avg`);
console.log(`new storage: ${(bytes / 1e15).toFixed(1)} PB/day, ${(bytes * 365 / 1e18).toFixed(2)} EB/year`);
console.log(`per mailbox: ${(perUser * avg * 365 / 1e9).toFixed(2)} GB/year before dedup`);

incoming: 40 billion messages/day = 462,963/s avg
new storage: 2.8 PB/day, 1.02 EB/year
per mailbox: 0.73 GB/year before dedup

Learn more: Search with an inverted index, Design a notification system and Design file storage and sync.

Clicks go through a redirect that logs them to Kafka, a stream processor aggregates per ad per minute with exactly-once state, results go to an OLAP store, and a nightly batch over the raw log reconciles the counts used for billing. "At an assumed 10 billion clicks a day that's about 116,000 a second on average and 350,000 at peak. The click endpoint records the event with a click id and redirects; Kafka is partitioned by ad id; Flink keeps per-(ad, minute) counts in checkpointed state and writes them idempotently, keyed by (ad, minute), so a replay overwrites rather than adds. Dashboards read the minute rollups, at most 2.9 billion rows a day. Because billing must be exact, the raw events also land in object storage and a batch job recomputes daily totals, deduplicated by click id, which is what invoices use."

// Ad click aggregation. Assumptions: 10 billion clicks a day, peak 3x, 2M active ads,
// advertisers query per-ad counts per minute; each event 200 bytes.
const clicks = 10e9, peak = 3, ads = 2e6, eventBytes = 200;
const avg = clicks / 86_400;
console.log(`clicks: ${Math.round(avg).toLocaleString("en-US")}/s avg, ${Math.round(avg * peak).toLocaleString("en-US")}/s peak`);
console.log(`raw events: ${(clicks * eventBytes / 1e12).toFixed(0)} TB/day`);
// Pre-aggregated: at most one row per (ad, minute) that had clicks.
const rowsPerDay = Math.min(ads * 1440, clicks);
console.log(`(ad, minute) rows: at most ${(rowsPerDay / 1e9).toFixed(2)} billion/day, ${(clicks / rowsPerDay).toFixed(1)} clicks per row on average`);
// Kafka partitions if one aggregator instance handles 20,000 events/s:
console.log(`aggregator partitions at 20,000 events/s each: ${Math.ceil(avg * peak / 20_000)}`);

clicks: 115,741/s avg, 347,222/s peak
raw events: 2 TB/day
(ad, minute) rows: at most 2.88 billion/day, 3.5 clicks per row on average
aggregator partitions at 20,000 events/s each: 18

Learn more: Batch vs stream processing, Idempotency and exactly-once and Resharding and hot partitions.

Count approximately in a stream, keep exact counts only for candidates: a count-min sketch plus a heap of the top k per window, merged across partitions. "With 500 million plays an hour, exact counts for every song in every window are wasteful when only the top 100 matter. Each stream partition keeps a count-min sketch for the current minute and a small heap of its heaviest songs; a merger combines the partitions' candidates every few seconds, and the hourly answer is the sum of the last 60 minute-windows. With ε = 10⁻⁵ the sketch is under 8 MB and over-counts by at most 5,000 plays, while the 100th song has about 100,000, so the ranking is reliable."

// Top-k "most played songs in the last hour". Count-min sketch sizing:
// width w = ceil(e / epsilon), depth d = ceil(ln(1 / delta)); error <= epsilon x N with probability 1 - delta.
const N = 500e6; // plays in the hour
for (const epsilon of [1e-4, 1e-5]) {
  const w = Math.ceil(Math.E / epsilon), d = Math.ceil(Math.log(1 / 0.001));
  console.log(`epsilon ${epsilon}: ${w.toLocaleString("en-US")} x ${d} counters = ` +
    `${((w * d * 4) / 1e6).toFixed(1)} MB, overcount <= ${(epsilon * N).toLocaleString("en-US")} plays`);
}
// A song in the top 100 usually has far more plays than that error, so its rank is reliable.
console.log(`hourly plays of the 100th song, if it gets 0.02% of plays: ${(N * 0.0002).toLocaleString("en-US")}`);

epsilon 0.0001: 27,183 x 7 counters = 0.8 MB, overcount <= 50,000 plays
epsilon 0.00001: 271,829 x 7 counters = 7.6 MB, overcount <= 5,000 plays
hourly plays of the 100th song, if it gets 0.02% of plays: 100,000

Learn more: HyperLogLog and count-min sketch and Design search autocomplete.

A chat service in front of a pool of model servers: requests stream back over SSE, a scheduler batches requests onto GPUs, conversation history lives in a normal database, and rate limits are in tokens, not requests. "At an assumed 50 million daily users sending 10 messages each, that's about 17,000 replies a second at peak, and because each reply streams for about 10 seconds, about 174,000 open streams at once: that concurrency, not the request rate, sizes the connection tier. The API server authenticates, loads the conversation, builds the prompt and sends it to an inference gateway that queues by model and priority and routes to servers with free capacity, preferably ones that already hold this conversation's prefix in cache. Tokens stream back over server-sent events, the way the major model APIs stream (Anthropic's Messages API documents SSE streaming, checked October 2026). The finished reply is saved with the conversation."

// An LLM chat assistant. Assumptions: 50M DAU x 10 messages a day, peak 3x, 200-token user messages,
// 2,000 tokens of context sent to the model per turn, 600 output tokens per reply streamed at 60 tokens/s.
const dau = 50e6, msgs = 10, peak = 3, userTokens = 200, contextTokens = 2_000, outTokens = 600, tokPerSec = 60;
const rps = (dau * msgs) / 86_400;
const streamSeconds = outTokens / tokPerSec;
const concurrent = rps * peak * streamSeconds; // Little's law: arrivals x duration
console.log(`replies: ${Math.round(rps).toLocaleString("en-US")}/s avg, ${Math.round(rps * peak).toLocaleString("en-US")}/s peak`);
console.log(`each reply streams for ${streamSeconds} s -> ${Math.round(concurrent).toLocaleString("en-US")} open streams at peak`);
console.log(`tokens at peak: ${(rps * peak * contextTokens / 1e6).toFixed(1)}M/s in (prefill), ${(rps * peak * outTokens / 1e6).toFixed(1)}M/s out (decode)`);
console.log(`stored history: ${(dau * msgs * (userTokens + outTokens) * 4 / 1e12).toFixed(1)} TB/day at ~4 bytes per token`);

replies: 5,787/s avg, 17,361/s peak
each reply streams for 10 s -> 173,611 open streams at peak
tokens at peak: 34.7M/s in (prefill), 10.4M/s out (decode)
stored history: 1.6 TB/day at ~4 bytes per token

Learn more: Real-time options: polling, long polling, SSE, WebSockets, Backpressure and load shedding and Rate limiting algorithms.

A partitioned, replicated append-only log: producers append to a partition's leader, followers replicate, consumers track offsets, and a controller decides leadership. "Each topic is split into partitions, each partition an ordered sequence of segment files on a broker, replicated to two followers. A write is acknowledged when the in-sync replicas have it (acks=all), so losing the leader loses nothing acknowledged. Consumers in a group each own some partitions and commit offsets, so the broker doesn't track individual messages, which is why it's fast and why replay is free. Partition count caps consumer parallelism, so it's sized for future peak, and retention is budgeted as rate × size × days × replicas."

// Sizing a Kafka topic. Assumptions: 100,000 events/s at peak, 1 KB each,
// one consumer instance handles 2,500 events/s, keep 7 days, replication factor 3.
const peak = 100_000, bytes = 1_000, perConsumer = 2_500, days = 7, rf = 3;
const avg = peak / 3; // peak is 3x the average
const minPartitions = Math.ceil(peak / perConsumer);
console.log(`partitions for parallelism: at least ${minPartitions} (plan ${minPartitions * 2} for growth)`);
const disk = avg * bytes * 86_400 * days * rf;
console.log(`disk: ${(disk / 1e12).toFixed(1)} TB for ${days} days x RF ${rf}`);
console.log(`peak ingest: ${(peak * bytes / 1e6).toFixed(0)} MB/s, x${rf} on the wire for replication`);

partitions for parallelism: at least 40 (plan 80 for growth)
disk: 60.5 TB for 7 days x RF 3
peak ingest: 100 MB/s, x3 on the wire for replication

Learn more: Queues vs logs, Delivery guarantees and ordering and Replication: leader-follower, multi-leader and leaderless.

Submissions go into a queue, sandboxed workers run them in short-lived microVMs or containers with strict limits, and results come back through polling or a push channel. "The submit endpoint stores the code with an id and returns 202. Workers pull jobs, start a fresh sandbox per submission (a microVM such as Firecracker, which documents boot in under 125 ms), compile, run each test with CPU, memory, time and no-network limits, and write the verdict. At an assumed contest peak of 167 submissions a second, each using about 6 seconds of one vCPU for 30 tests, that's about 1,000 busy vCPUs, 1,500 at a safe utilisation. Contests get their own queue and pre-scaled workers, so practice traffic can't delay them."

// An online judge during a contest. Assumptions: 50,000 contestants, 1 submission each per 5 minutes
// at the peak, 30 test cases per submission, 0.2 s CPU per test, one sandbox per submission on 1 vCPU,
// plus 0.15 s to start a microVM (Firecracker documents < 125 ms boot).
const contestants = 50_000, every = 300, tests = 30, perTest = 0.2, start = 0.15;
const rate = contestants / every; // submissions per second
const busy = start + tests * perTest; // seconds of one vCPU per submission
const vcpus = rate * busy; // Little's law: in-flight sandboxes
console.log(`submissions: ${rate.toFixed(0)}/s at peak, ${busy.toFixed(2)} s of vCPU each`);
console.log(`busy vCPUs: ${Math.ceil(vcpus).toLocaleString("en-US")} (run at 70%: ${Math.ceil(vcpus / 0.7).toLocaleString("en-US")})`);
// Slow or looping code: 10% of submissions run 5 tests to a 2 s time limit (1.8 s more than usual each).
console.log(`with 10% hitting the 2 s limit on 5 tests: +${Math.round(rate * 0.1 * 5 * (2 - perTest))} busy vCPUs`);

submissions: 167/s at peak, 6.15 s of vCPU each
busy vCPUs: 1,025 (run at 70%: 1,465)
with 10% hitting the 2 s limit on 5 tests: +150 busy vCPUs

Learn more: Why queues, Design a notification system and Design a leaderboard.

A chat system where one room has millions of readers, so the design is about fan-out: viewers hold a connection to a gateway, comments are written once and published per stream, and each viewer gets a sampled, batched feed rather than every comment. "With an assumed 2 million viewers and 3,000 comments a second, sending everything to everyone is 6 billion messages a second, and nobody can read 3,000 comments a second anyway. So the comment service stores each comment, publishes it to the stream's channel, and a per-stream sampler picks about 10 a second (friends' comments and highly rated ones first) for broadcast. Gateways subscribe once per stream and push one batched frame every 500 ms to each of their viewers: 4 million frames a second across about 20 gateways."

// Live comments on one big stream. Assumptions: 2M concurrent viewers, 3,000 comments/s posted,
// each viewer's screen can usefully show about 10 new comments a second.
const viewers = 2e6, posted = 3_000, shown = 10;
const naive = viewers * posted;
console.log(`send every comment to every viewer: ${(naive / 1e9).toFixed(0)} billion messages/s`);
const sampled = viewers * Math.min(shown, posted);
console.log(`sample to ${shown}/s per viewer: ${(sampled / 1e6).toFixed(0)}M messages/s (${(naive / sampled).toFixed(0)}x less)`);
// Batch them: one frame per viewer every 500 ms carrying ~5 comments.
console.log(`batched every 500 ms: ${(viewers * 2 / 1e6).toFixed(0)}M frames/s`);
console.log(`gateways at 100,000 viewers each: ${viewers / 100_000}`);

send every comment to every viewer: 6 billion messages/s
sample to 10/s per viewer: 20M messages/s (300x less)
batched every 500 ms: 4M frames/s
gateways at 100,000 viewers each: 20

Learn more: Scaling WebSockets, Design a chat system and Pub/sub and fan-out.

RADIO: requirements, architecture, data model, interface, optimisations, with most of the time on the last one. "Requirements include devices, network, SEO and accessibility targets, with numbers: LCP under 2.5 s on a mid-range phone. Architecture is the component tree and the rendering strategy. The data model is the client entities and who owns each piece of state. The interface is the server API the UI needs (pagination, fields, real-time) and the component contracts. Optimisations are performance, loading, offline, accessibility and security, which is where the depth is."

Learn more: The frontend system design round.

Choose per route from three questions: must it be indexed or previewed, is it different per user, and how often does it change? "Marketing and docs: static generation on a CDN. Product pages, the same for everyone but changing: incremental regeneration or SSR behind a short CDN cache with revalidation. Personalised and indexed pages: streamed SSR, with the per-user parts kept out of shared caches. The logged-in dashboard: client-side rendering behind a cached shell. And whatever the strategy, I limit what hydrates, because rendering decides when content appears but JavaScript decides when it responds."

Learn more: Rendering strategies for an app.

Search results are server state in a query cache, filters are URL state, the theme is client state in a small store. "I classify state by owner. Server data belongs to the server, so the client holds a cache of it keyed by query, with staleness rules. Anything shareable or that Back should restore, like filters, sort and the cursor, belongs in the URL. Session-wide UI preferences live in a small client store, and everything else is local to the component. Each fact has one owner and the rest is derived, so 'filtered items' is computed, not stored."

Learn more: State: server state, client state and URL state and Design a data table.

They see the cached data instantly, and it quietly updates a moment later if the server has something newer; a spinner appears only the very first time. "The query cache serves fresh data without a request, serves stale data immediately while refetching in the background, and dedupes concurrent requests for the same key. Each kind of data gets a staleness time matching how old it may be. After our own mutations I invalidate the affected keys, or update them optimistically with a rollback."

Learn more: Data fetching and client caching.

About 20 to 25, whatever the list's length: the visible rows plus the overscan. "I'd render a spacer as tall as the whole list (560,000 px here), position only the rows in the window at their offsets, and recompute the window on scroll. Variable heights need measured or estimated heights and a binary search over their running offsets. The costs are find-in-page, focus and scroll restoration, which I'd handle explicitly."

// Windowing maths for a virtualised list: 10,000 rows of 56 px, an 800 px viewport, 5 rows of overscan.
const rows = 10_000, rowHeight = 56, viewport = 800, overscan = 5;
function windowAt(scrollTop) {
  const first = Math.max(0, Math.floor(scrollTop / rowHeight) - overscan);
  const last = Math.min(rows - 1, Math.ceil((scrollTop + viewport) / rowHeight) - 1 + overscan);
  return { first, last, rendered: last - first + 1, offset: first * rowHeight };
}
console.log(`spacer height: ${(rows * rowHeight).toLocaleString("en-US")} px`);
for (const top of [0, 28_000, rows * rowHeight - viewport]) {
  const w = windowAt(top);
  console.log(`scrollTop ${String(top).padStart(6)}: rows ${w.first}-${w.last} (${w.rendered} in the DOM), first at ${w.offset} px`);
}

spacer height: 560,000 px
scrollTop      0: rows 0-19 (20 in the DOM), first at 0 px
scrollTop  28000: rows 495-519 (25 in the DOM), first at 27720 px
scrollTop 559200: rows 9980-9999 (20 in the DOM), first at 558880 px

Learn more: Infinite scroll and list virtualisation and Design a news feed UI.

Cursor pagination, a prefetch threshold, dedup by id, a new-posts banner instead of inserting at the top, and virtualisation once the list gets long. "I fetch the next page when the last rendered item is within a few cards of the end, with the in-flight request deduplicated and an explicit end state. Pages come by cursor, because new posts at the top would make offsets repeat posts, and the store still dedups by id because ranking can repeat a post. New posts show as a banner that inserts them on tap, so content never jumps under the reader."

Learn more: Design a news feed UI and Pagination at the API level.

Debouncing sends a request only when the user pauses, which turns 13 keystrokes into about 3 requests; it also needs latest-request-wins and a cache. "I'd debounce at about 250 ms, because an average typist presses a key about every 230 ms, so requests fire on pauses. Responses can arrive out of order, so each request gets a ticket and only the latest one is shown, with an AbortController to cancel the old ones. A per-query cache makes backspacing free, and the endpoint is a cacheable GET /suggest?q= so a CDN serves popular prefixes."

// How many requests does typing "system design" send? Gaps between keystrokes in ms (a fake clock),
// with a 600 ms pause after "system" and a 400 ms pause after "sys".
const text = "system design";
const gaps = [0, 210, 190, 400, 220, 180, 600, 230, 200, 240, 210, 190, 230];
function requests(debounceMs) {
  const sent = [];
  let t = 0, timer = null;
  for (let i = 0; i < text.length; i++) {
    t += gaps[i];
    if (timer && timer.at <= t) sent.push(timer.q); // the pending call fired before this key
    timer = { at: t + debounceMs, q: text.slice(0, i + 1) };
  }
  sent.push(timer.q); // the last one fires after typing stops
  return sent;
}
console.log(`no debounce: ${text.length} requests`);
for (const ms of [150, 250, 500]) {
  const r = requests(ms);
  const list = r.length <= 4 ? ` -> ${r.map((q) => JSON.stringify(q)).join(", ")}` : " (one per key)";
  console.log(`debounce ${ms} ms: ${r.length} requests${list}`);
}

no debounce: 13 requests
debounce 150 ms: 13 requests (one per key)
debounce 250 ms: 3 requests -> "sys", "system", "system design"
debounce 500 ms: 2 requests -> "system", "system design"

Learn more: Design an autocomplete component.

LCP at most 2.5 s, INP at most 200 ms, CLS at most 0.1, each judged at the 75th percentile of real visits, per device type. "LCP moves with the critical path: server-render the first view, serve from a CDN, put the hero image in the HTML with fetchpriority=high at the right size. INP moves with main-thread work: small handlers, yielding in long tasks, virtualised lists, fewer third-party scripts. CLS moves with reserved space: dimensions on media, reserved ad slots, banners that overlay instead of pushing content."

Learn more: Web performance budgets and Core Web Vitals.

The 1080 px file: the browser needs slot width × device pixel ratio, 360 × 3 = 1,080 device pixels. "That's why sizes must be accurate: without it the browser assumes the image fills the viewport and may pick a far bigger file. Capping at 2× would load the 768 px file instead, roughly half the bytes, which is usually invisible on a phone. Images come from an image CDN in AVIF or WebP, lazy below the fold, and the LCP image is eager with high fetch priority."

// Which srcset candidate does a browser need? Slot width (CSS px, from `sizes`) x device pixel ratio,
// rounded up to the next candidate.
const candidates = [480, 768, 1080, 1440, 1920];
const pick = (slotCss, dpr) => candidates.find((w) => w >= slotCss * dpr) ?? candidates.at(-1);
for (const [device, slot, dpr] of [["phone", 360, 3], ["phone, capped at 2x", 360, 2], ["tablet", 768, 2], ["laptop", 600, 1]]) {
  console.log(`${device.padEnd(20)} ${slot} px slot x ${dpr} = ${slot * dpr} px -> loads the ${pick(slot, dpr)}w file`);
}

phone                360 px slot x 3 = 1080 px -> loads the 1080w file
phone, capped at 2x  360 px slot x 2 = 720 px -> loads the 768w file
tablet               768 px slot x 2 = 1536 px -> loads the 1920w file
laptop               600 px slot x 1 = 600 px -> loads the 768w file

Learn more: Loading strategy: code splitting, prefetching and images and Design an image carousel and gallery.

Because without it every client retries at the same moment and the reconnects arrive as one spike; full jitter spreads them over the whole backoff window. "Clients reconnect with exponential backoff, capped at about 30 seconds, and a random delay between zero and the current cap. They reset the backoff only after a connection has stayed up for a while, resume from their last sequence number, and do a full refetch if they're too far behind."

// 10,000 clients lose their WebSocket at t = 0 and reconnect after a delay. How many arrive in the
// busiest 100 ms? Full jitter: delay = random(0, min(cap, base * 2^attempt)). Seeded PRNG (mulberry32).
function mulberry32(seed) {
  return () => {
    seed |= 0; seed = (seed + 0x6d2b79f5) | 0;
    let t = Math.imul(seed ^ (seed >>> 15), 1 | seed);
    t = (t + Math.imul(t ^ (t >>> 7), 61 | t)) ^ t;
    return ((t ^ (t >>> 14)) >>> 0) / 4294967296;
  };
}
const clients = 10_000, base = 1000, cap = 30_000;
const busiest = (delays) => {
  const buckets = new Map();
  for (const d of delays) buckets.set(Math.floor(d / 100), (buckets.get(Math.floor(d / 100)) ?? 0) + 1);
  return Math.max(...buckets.values());
};
const fixed = Array.from({ length: clients }, () => base); // everyone waits exactly 1 s
const rand = mulberry32(42);
const jittered = Array.from({ length: clients }, () => rand() * Math.min(cap, base * 2 ** 3)); // 4th attempt: up to 8 s
console.log(`fixed 1 s delay:     busiest 100 ms gets ${busiest(fixed).toLocaleString("en-US")} reconnects`);
console.log(`full jitter, 0-8 s:  busiest 100 ms gets ${busiest(jittered)} reconnects`);
console.log(`caps per attempt: ${[0, 1, 2, 3, 4, 5, 6].map((a) => Math.min(cap, base * 2 ** a) / 1000 + " s").join(", ")}`);

fixed 1 s delay:     busiest 100 ms gets 10,000 reconnects
full jitter, 0-8 s:  busiest 100 ms gets 158 reconnects
caps per attempt: 1 s, 2 s, 4 s, 8 s, 16 s, 30 s, 30 s

Learn more: Real-time updates in the client and Retries, dead-letter queues and poison messages.

They're sorted by each sender's device clock; order must come from the server's per-conversation sequence number. "Device clocks drift and are set by hand, so createdAt can put a reply above its question. The server assigns a gap-free seq per thread when it stores the message and acks with it. The client shows confirmed messages by seq, pending ones after them, never reorders a confirmed message, and because seqs have no gaps it can detect missing messages and fetch the exact range."

Learn more: Design a chat app UI and Design a chat system.

A service worker with a strategy per request type, plus an outbox for writes. "The app shell and versioned assets are precached and served cache-first, which is safe because content-hashed URLs never change. Navigations are network-first with a short timeout, falling back to the cached page. Personal API data stays network-only or goes into IndexedDB that's cleared on logout. Offline writes go into an IndexedDB outbox with idempotency keys and replay on reconnect, with Background Sync where it exists, which is only Chromium."

Learn more: Offline support and service workers.

Ideally not in JavaScript at all: a backend for frontend holds the OAuth tokens and the browser gets an HttpOnly, Secure, SameSite session cookie. "Anything JavaScript can read, an XSS bug can steal, so tokens in localStorage are one injection away from leaking. With a session cookie, CSRF becomes the threat instead, so state-changing requests check the Origin header or a CSRF token, and nothing changes state on GET. Against XSS itself: the framework's escaping, no raw-HTML sinks without DOMPurify, a strict nonce-based CSP and Trusted Types."

Learn more: Frontend security.

OT when there's always a central server and you want compact operations; a CRDT such as Yjs when you need offline editing or peer-to-peer and can afford the metadata. "Both solve convergence under concurrent edits, where 'insert at 3' means something different once someone else has inserted before 3. With OT the server defines one order and transforms late operations against everything since their base revision. With a CRDT each character has a unique id and an anchor, deletes are tombstones, and replicas converge in any delivery order."

Learn more: Design a collaborative document editor and Conflict resolution: last-write-wins and CRDTs.

One idempotency key per checkout attempt, sent with the place-order request and reused on every retry; the server recomputes every amount and rejects a changed cart version. "Disabling the button helps the common case, but timeouts, retries and a second tab still produce duplicates, so the server is what guarantees it: it claims the key atomically and returns the first result for any repeat. The browser never decides prices or totals, and the payment provider's webhook, not the browser, marks the order paid."

Learn more: Design an e-commerce product page and checkout and Idempotency keys for APIs.

Only when the problem is team independence: several teams blocked on each other's releases, or parts of the product with very different lifecycles. "Then I'd split by route first, separate apps behind one domain, and use runtime composition such as Module Federation only where parts must share a page. I'd budget for the costs: a shell owned by a platform team, a design system, agreed shared dependency versions so the framework loads once, explicit contracts, and an error boundary and timeout around each remote. For one or two teams, a monorepo with enforced module boundaries gives most of the benefit without the runtime cost."

Learn more: Micro-frontends and monorepos.

In the platform: accessible primitives in the design system, app-level behaviour in the shell, and automated checks in CI. "The design system ships components that implement the APG patterns (keyboard, focus, ARIA) and tokens that pass WCAG 2.2 AA contrast, checked in its build. The app shell handles what no component can: on every client-side navigation it updates the title and moves focus to the new page's heading. Teams get lint rules and axe in end-to-end tests, plus manual screen-reader checks before release."

Learn more: Accessibility and internationalisation at scale and Design a design system and component library.