The System Design Fundamentals Handbook
Day one: the four questions underneath every design, covering partitions and consistency, concurrent writes, splitting and copying data, and getting machines to agree, plus why stateless services scale horizontally. Don't try to memorize it; read it once to learn the words, then return after the first week of designs, when each section will map onto something you have already built.
Interactive Capacity Estimator
The habit to build before any design: turn daily users into requests per second, peak QPS, storage per year, bandwidth and node counts, with the formula shown beside each number. Use it once per design this month, estimating by hand first and checking with the sliders, so that by week four the two-minute estimate at the top of an answer is automatic.
CAP Theorem & Consistency Models
CAP as it applies to real choices: what a partition forces, why "CA" is a myth, the latency-versus-consistency trade-off PACELC adds for normal operation, and the consistency spectrum from linearizable to eventual. Every design later this month makes a per-operation consistency decision, and this page gives you the words to state it, such as strong for a balance and eventual for a view count.
Design a URL Shortener
Your first full design, small enough to finish in one sitting: a server that writes and redirects, base-62 codes from a key-generation service, a read-heavy path with caching, scale-out, sharding, analytics behind a queue, and expiry and abuse handling. Before reading, spend fifteen minutes designing it yourself, then compare; the gaps you find are what the rest of the month fixes.
Design a Rate Limiter
A design about counting correctly at scale: rejecting early at the gateway, choosing what to limit per user or per key, token bucket versus window algorithms, atomic counters shared by many gateways, regional placement, and fail-open versus fail-closed behavior. It sets up the next step, so note exactly how the token bucket refills and what state it keeps for each client.
Token Bucket Rate Limiter
The one implementation exercise of the month: write token_bucket(capacity, rate, times) so that a bucket starting full refills lazily, credits the time elapsed since the last request, caps at capacity, and accepts only when a whole token is available. Passing the hidden tests proves you understood the design you just read, and the same function makes a plausible coding follow-up to a rate-limiter question.
Design a Key-Value Store
The storage layer under most of the designs to come, built Dynamo-style: consistent hashing, replication along a preference list, R and W quorums, conflict resolution, gossip membership, hinted handoff and read repair. Take this one slowly; when later designs say "store it in a key-value store", you should know what that store does when a node fails and why it favors availability.
The Caching Patterns Handbook
The arithmetic of caching: average latency as a hit-rate-weighted blend of the fast and slow paths, why a small change in hit rate moves latency so much, the cache-aside, write-through and write-back patterns, TTLs, and the two hard problems of invalidation and stampedes. It prepares you to justify a cache with numbers in any design, rather than adding one by reflex.
Design a Distributed Cache
The cache as its own distributed system: cache-aside, sharding with consistent hashing rather than modulo, LRU, LFU and TTL eviction, replication and failover, invalidation, and coalescing misses during a thundering herd. Coming right after the caching handbook, it shows the operational side and prepares you for follow-ups about hot keys, choosing a TTL, and whether the cache is ever the source of truth.
Consistent Hashing Visualizer
A quick hands-on break: add and remove servers on a hash ring, change the virtual-node count, and watch which keys move and how balanced the load becomes. Spend ten minutes here after the cache and key-value designs, since both rely on the ring, until you can predict before clicking roughly how many keys a new node will take.
Design a News Feed
The start of the fan-out week: separating posts from feeds, pull versus push fan-out with the costs of each, ranking candidates, a hybrid for accounts with huge followings, mixing sources, and pagination with deduplication and freshness. Design it yourself first with one question in mind, which is whether the work should happen when someone posts or when someone reads.
Design Twitter
The same fan-out question at a harsher scale: an immutable tweet store, a directed follow graph, precomputed home-timeline inboxes, sharding by access key, retrieve-then-rank, and the celebrity problem that forces hybrid fan-out. Compare it with the news feed you just did and write down what changed and why, because seeing one pattern under different constraints is the skill this month builds.
Design WhatsApp
Real-time messaging instead of feeds: persistent connections that push rather than poll, finding which server a user is connected to, store-and-forward for offline delivery, sent, delivered and read receipts built from acknowledgments, group fan-out, media kept off the socket, and end-to-end encryption. It prepares you for chat prompts and for the question of how a handful of servers can hold billions of connections.
Design a Notification System
A pipeline design: one API for every producer, a queue to decouple them from delivery, user preferences as a gate, rendering once and fanning out through push, SMS and email adapters, scheduled sends, delivery tracking with retries, and protection against duplicates and floods. It is good practice for the "what if a downstream provider goes down?" style of question that pipeline designs attract.
Partitioning, Sharding & Replication
A mid-month consolidation: by now you have sharded URLs, a key-value store and timelines, and this handbook names what you were doing, covering range, hash and directory partitioning, consistent hashing, hot partitions and shard keys, and replication topologies tied together by quorums. Use it to revisit one earlier design and justify its partition key properly.
Design a Message Queue
The async backbone that several earlier designs assumed: an append-only log, partitions with per-partition ordering, consumer groups and offsets, leader and in-sync-replica replication, retention and compaction, and delivery guarantees. After this you can say precisely what "put it on a queue" means in your own diagrams, including how many partitions you need and what delivery semantics you are promising.
Design a Search Engine
An inverted index from scratch: analyzing queries and documents the same way, building postings offline and serving them online, ranking by relevance and authority, sharding with scatter-gather, caching hot queries, and keeping the index fresh. It prepares you for search prompts and for the tail-latency question that scatter-gather raises, since every query waits for its slowest shard.
Design YouTube
Video at scale, which is mostly a storage and delivery problem: metadata split from blobs, transcoding one upload into many renditions for adaptive bitrate, serving through a CDN, hot and cold storage tiers, separate read and write planes, view events, and the unhappy paths of uploads, copyright and live. Expect follow-ups on adaptive bitrate and resumable uploads, both covered on the page.
Design Uber
Real-time geospatial matching: a hot path for driver locations kept apart from durable trip data, geospatial indexing to answer who is nearby, picking a driver when two riders want the same one, scaling to millions of trips a day, live map updates, and the trip lifecycle through payment. It prepares you for location prompts and for the race conditions interviewers like to add.
Design a Payment System
The month's correctness capstone: an authorize-and-capture state machine, idempotency keys that make retries safe, a double-entry ledger, tokenization to contain card data, webhooks for asynchronous events, and reconciliation with the provider. Where earlier designs could accept stale reads, this one cannot, so practice explaining which parts need strong consistency and how you avoid charging anyone twice.
50 System Design Interview Questions
Fifty questions with short answers you can say out loud, across requirements, networking and load balancing, caching, storage, CAP, messaging, reliability and design scenarios, including a runnable demonstration of why fan-out makes tail latency the common case. Use it in the final days as a self-test: answer each question from the designs you built this month before reading the written version.