System Design Handbook · llms.txt
Reading about system design teaches you the parts. Answering questions out loud teaches you to use them. This chapter is a bank of questions to practise on, with pointers to the chapters that help and to articles that show how real companies solved the same problem.
Here is one way to practise a question, say "Design a chat app like WhatsApp":
The chapter has four parts:
These chapters each take one question from requirements to a scaled design. The system design chapters follow the same four steps you'll use in an interview, so you can compare your answer with one laid out the same way.
| Question | What it teaches |
|---|---|
| Design a text-sharing service like Pastebin | Keeping small records (code, expiry) apart from the larger text they point to, cleaning up expired data, and serving a read-heavy service. Also asked as "Design Bit.ly", which is closer to the URL shortener below. |
| Design the Twitter timeline and search | Where to do the work for a feed: when a post is written (fan-out on write) or when a timeline is read, and what to do about accounts with millions of followers. Also asked as "Design the Facebook feed and search". |
| Design a web crawler | Managing a to-do list of billions of links, skipping duplicate pages, and crawling politely without overloading any one site. |
| Design a personal finance tracker like Mint | Pulling data from outside systems in background workers, categorising it, and splitting a write-heavy workload from the reads users see. |
| Design the data structures for a social network | Finding the shortest path between two people when friend lists are spread across many servers, while keeping the number of network calls small. |
| Design a key-value cache for a search engine's query results | An in-memory cache with least-recently-used eviction, spread over many machines, with a plan for hot keys and stale results. |
| Design Amazon's sales rank by category | Separating a large, slow batch job that computes an answer from a small, fast path that serves it. |
| Design a system that scales to millions of users on AWS | Growing one site from a single server to many, one bottleneck at a time, and knowing when each fix is worth its cost. |
| Design a URL shortener (like TinyURL or Bitly) | Generating short codes that never collide, choosing a redirect status code, sharding a table with billions of rows, and counting clicks cheaply. |
| Design a social media news feed | Push versus pull feeds, caching feeds for hundreds of millions of users, paging through a list that keeps changing, and ranking. |
| Design a real-time gaming leaderboard | Answering "what's my rank?" among millions of players quickly, with sorted sets built on skip lists, and breaking ties fairly. |
| Design a payment system and gateway | Making retries safe with idempotency keys, tracking each payment in a state machine, keeping a double-entry ledger, and reconciling with outside providers. |
| Design a collaborative document editor | Merging edits that two people make at the same moment, with operational transformation or CRDTs, so every screen ends up showing the same text. |
| Design a web search engine | Building an inverted index, splitting it across machines, and ranking results within a couple of hundred milliseconds. |
| Design a personalized recommendation system | Narrowing a catalog of millions of items to twenty in stages, so the expensive model only scores a few hundred candidates. |
| Design a distributed key-value store | Partitioning, replication, quorums, conflict resolution and failure detection, all in one design. |
| Design a notification system | Queues, retries, deduplication and rate limits across several outside providers, without letting a marketing blast delay a login code. |
| Design a chat system | Long-lived connections, message ordering, delivery and read receipts, and keeping several devices per user in sync. |
| Design search autocomplete (typeahead) | Separating an offline pipeline that builds suggestions from an online lookup that answers in milliseconds, and caching almost everything. |
| Design a video streaming platform | Uploading very large files reliably, transcoding in parallel, adaptive bitrate streaming, and why bandwidth cost shapes the design. |
| Design a file sync service (like Dropbox or Google Drive) | Keeping strongly consistent file metadata apart from file content, splitting files into blocks, and handling conflicts from offline edits. |
| Question | What it teaches |
|---|---|
| Design a hash map | Turning a key into an array index, handling collisions, and growing the table as it fills. |
| Design an LRU cache | Combining a hash map with a linked list so that lookups and evictions both take constant time. |
| Design a call center | Escalating work through a chain of employees and queuing callers when everyone is busy. |
| Design a deck of cards | Modelling a general structure once and letting each game (such as blackjack) give it its own rules through inheritance. |
| Design a parking lot | Matching vehicles of different sizes to spots, including a vehicle that needs several spots side by side. |
| Design a chat server | Users, friend requests, private chats and group chats as classes, with rules about who may post where. |
The handbook doesn't work these questions through in full. Each one lists what makes it hard, the chapters that cover the parts you'll need, and references that show how others have answered it. Most of them overlap with a worked design, so do that one first and then try the variation.
The references were checked when this chapter was written. Some are old. Treat the numbers in them as a snapshot of that time, and read them for the reasoning.
Design a file sync service like Dropbox.
Design a key-value store like Redis.
Design a cache system like Memcached.
Design a garbage collection system.
Design a system that serves data from multiple data centers.
Design a content delivery network like Cloudflare.
Design a chat app like WhatsApp.
Design the Facebook chat function.
Design a picture sharing system like Instagram.
Design the Facebook news feed function.
Design the Facebook timeline function.
Design Google Docs.
Design a search engine like Google.
Design a scalable web crawler like Google's.
Design a graph search function like Facebook's.
Design a trending topic system like Twitter's.
Return the top k requests during a time interval.
Design a recommendation system like Amazon's.
Design a stock exchange (like NASDAQ or Binance).
Design an online multiplayer card game.
Design a tinyurl system like Bitly.
Design a random ID generation system.
Design an API rate limiter.
These questions come up often in interviews today. They have no references here, but each is close to a worked design, so you can check most of your answer against it.
| Question | What makes it hard | Chapters that help |
|---|---|---|
| Design a ride-hailing service's driver matching | Finding nearby drivers among millions of moving points, updated every few seconds. | Real-time communication, NoSQL databases, Design a notification system |
| Design a ticket booking system for a big concert | Selling each seat exactly once while a huge crowd arrives in the same minute. | Distributed transactions, Rate limiting, Design a payment system |
| Design a distributed job scheduler | Running each job once and on time, even when the machine that was going to run it fails. | Queues and async work, Consensus, Reliability patterns |
| Design a metrics and monitoring system | Storing a flood of small time-stamped numbers cheaply and answering queries over them quickly. | Observability, Event streaming, NoSQL databases |
| Design a distributed message queue | Keeping messages durable and in order while many producers and consumers come and go. | Queues and async work, Event streaming, Consensus |
| Design an ad click counter | Counting billions of clicks accurately enough to bill for them, without counting any click twice. | Event streaming, Batch processing, Design Amazon's sales rank by category |
In an object-oriented design question you design the classes, their fields and methods, and how they work together, for a program that runs on one machine. Start by listing the nouns in the problem (they become classes) and the verbs (they become methods). Then write the main methods in code.
Design a circular array.
A circular array is a fixed-size array whose end wraps around to its start. Picture a queue of the last 1,000 log lines: when line 1,001 arrives, it overwrites line 1 instead of growing the array.
start offset. The item at logical position i lives at index (start + i) % capacity. Rotating the array by k then means only changing start, which takes constant time instead of moving every item. Decide what append does when the array is full (overwrite the oldest item, raise an error or grow), make the class iterable in logical order, and test the wrap-around at the end of the list.% and has to decide what to do when it fills up.The questions below are common in interviews. They aren't worked through in the handbook, so use the hint and the closest chapter to check your approach.
| Question | Hint | Closest worked chapter |
|---|---|---|
| Design an elevator system | Separate the elevator car (its floor, direction and stops) from the controller that decides which car answers each call. | Design a call center, which also assigns incoming requests to whoever is free |
| Design a vending machine | Model the machine as a set of states (idle, has money, dispensing) with the allowed moves between them. | Design a parking lot |
| Design a library management system | Books, copies of a book, members and loans are separate classes. A loan links one copy to one member with a due date. | Design a parking lot, where spots, vehicles and levels play similar roles |
| Design a movie ticket booking system | Two people must not book the same seat. Hold seats for a few minutes while someone pays, then release them. | Design a parking lot |
| Design a chess game | A Piece base class with one subclass per piece type, each knowing its own legal moves. The board checks the rules that involve several pieces. | Design a deck of cards, which uses the same base-class-and-subclass pattern |
| Design an in-memory file system | Files and directories share a base class, and a directory holds children, which can be either. Paths are walked one name at a time. | Design a hash map, for looking up children by name |
| Design a text editor with undo and redo | Store each edit as an object that knows how to apply and reverse itself, and keep two stacks of them. | Design an LRU cache, for another design built from two cooperating data structures |
A short plan you can keep up for a few weeks:
After each attempt, review your answer against this checklist:
Practising with a partner is closer to the real thing than practising alone. One person plays the interviewer and keeps the question vague at first, so the other has to ask. The interviewer answers questions about scale with numbers, pushes on one component ("what happens if this cache goes down?"), and keeps time. Afterwards, go through the checklist together, then swap roles. Playing the interviewer teaches you a lot too, because you see which answers are easy to follow.
If you only read a few of the references above, start with these. Each one explains a decision you'll face again and again.
Previous: Numbers to know · Next: Real-world architectures