The System Design Fundamentals Handbook
The four ideas every prompt leans on: CAP and the consistency spectrum, concurrency and locking, partitioning and replication, and consensus, plus statelessness, horizontal scaling and a back-of-the-envelope primer. Read it to collect the vocabulary interviewers expect, then practice answering "why is your app tier stateless?" and "which reads can be eventually consistent here?" in one or two sentences each.
CAP Theorem & Consistency Models
What CAP actually claims, why "CA" is not a real option, how PACELC adds the latency trade-off you pay even without a partition, and the spectrum from linearizable to causal to eventual consistency. You also prove the quorum rule, that R + W must exceed N, by brute force. That prepares you for the classic follow-up: during a partition, does this design refuse requests or serve stale data, and which is acceptable for which data?
Partitioning, Sharding & Replication
Partitioning and replication answer two different questions, and this handbook keeps them apart: range, hash and directory partitioning, consistent hashing with virtual nodes, hot partitions and choosing a shard key, then single-leader, multi-leader and leaderless replication tied together by quorums. It readies you for "how would you shard this table?", where a strong answer names the shard key, the hot-key risk and what happens when a node joins.
Concurrency, Locks & Isolation Levels
Covers the races that break correctness, such as lost updates, dirty reads and double-spends, and the tools against them: pessimistic versus optimistic locking, the four SQL isolation levels and the anomalies each allows, MVCC, and distributed locks with fencing tokens. Interviewers reach for this when two users try to book the last seat at once, so practice saying which isolation level or version check you would use and why.
Consensus, Transactions & Coordination
Why agreement between machines is hard, how Raft and Paxos use majority quorums to elect a leader, what coordination services like ZooKeeper and etcd are for, two-phase commit versus sagas, and idempotency as the practical answer to "exactly once". At interview depth you rarely implement any of it; you need to say when a design needs consensus at all and why a five-node cluster survives two failures.
Interactive Capacity Estimator
Slide daily active users, requests per user, read ratio, payload size, replication and peak factor, and watch QPS, storage per year, bandwidth, node count and cache memory recompute with the formula shown for each. Use it to rehearse the two-minute estimate that opens a design answer, until the 86,400-seconds-a-day arithmetic is automatic and you can say what the result means for the architecture.
Consistent Hashing Visualizer
An interactive hash ring: add and remove nodes, change the number of virtual nodes, and watch which keys move and how evenly load spreads. It turns a common follow-up into something you have seen, namely why modulo hashing reshuffles almost every key when a server is added while a ring moves only about K/N of them.
Design a URL Shortener
The gentlest full design, built piece by piece: minting base-62 codes, a read path that dwarfs the write path, caching and scaling out, sharding billions of rows, click analytics behind a queue, and aliases, expiry and abuse. Rehearse it first because its follow-ups are well known, such as 301 versus 302 redirects and why a key-generation service beats per-server counters, and the page closes with how to open the answer in an interview.
Design a Rate Limiter
A focused prompt that rewards precision: where the limiter lives, what key you limit on, token bucket versus sliding windows, keeping one counter correct across many gateways with atomic operations, one Redis or one per region, and whether to fail open or closed when the store is down. The page's interviewer follow-ups press on exactly those choices, so practice defending each one in a sentence.
Design a Key-Value Store
A Dynamo-style store assembled step by step: consistent hashing, replication along a preference list, quorum reads and writes, conflict resolution, gossip membership, hinted handoff and read repair. This is where the handbook concepts meet a real prompt, so answer the page's follow-ups out loud, including why the design chooses availability over consistency and whether a read can still be stale when R + W exceeds N.
Design a News Feed
The fan-out problem in full: pull on read, push on write, the hybrid that handles accounts with huge followings, ranking candidates, mixing sources, and pagination with deduplication. It prepares you for read-heavy social prompts and their standard probes, such as what happens to a post deleted after fanning out to a million feeds and how ranking stays fast on every read.
Design a Payment System
The design where consistency is not negotiable: authorize then capture as a state machine, idempotency keys so retries cannot double-charge, a double-entry ledger, tokenization to shrink PCI scope, webhooks for slow external events, and reconciliation against the provider. It closes the path because it tests whether you can say no to eventual consistency, and you should expect questions about refunds, chargebacks and keeping your ledger in step with the payment provider.