Updated 26 October 2026
The best system design books and papers for interviews
The books worth reading for system design interviews and what each is for (Designing Data-Intensive Applications, Alex Xu's System Design Interview, Understanding Distributed Systems, Database Internals and more), the dozen papers behind the classic questions, and the order to read them in.
There is no single book that gets you through a system design interview, and reading more than three is usually a way of avoiding practice. The useful question is what each one is for. Some teach how storage and distributed systems actually work, which is what the deep dives test. Some walk through the classic interview questions end to end. And a dozen papers describe the real systems that interviewers have in mind when they ask you to design a key-value store or a message queue. This guide sorts them by job, says who each is for, and maps the papers to the questions they explain.
The short list
If you read only three things, read these, in this order:
- One interview book, to learn the shape of a 45-minute answer: Alex Xu's *System Design Interview: An Insider's Guide* (volume 1).
- Designing Data-Intensive Applications by Martin Kleppmann, for the depth behind the deep dives: replication, partitioning, transactions, consistency, stream processing.
- The Dynamo paper, because it is the clearest description of the trade-offs behind half the questions you will be asked.
Then stop reading and start practicing whole answers out loud. The structure for that is in how to run a system design interview.
Books for the deep dives
| Book | Author | What it is for | Who should read it |
|---|---|---|---|
| Designing Data-Intensive Applications | Martin Kleppmann | How databases, replication, partitioning, transactions and stream processing really behave, and the trade-offs between them | Everyone preparing for senior and staff loops; the single most useful book |
| Understanding Distributed Systems | Roberto Vitillo | A shorter, practical tour: communication, coordination, scalability, resiliency and operations | Mid-level engineers who want the map before the depth |
| Database Internals | Alex Petrov | Storage engines (B-trees, LSM trees) and the distributed side (failure detection, replication, consensus) | Anyone interviewing for storage or infrastructure teams |
| Site Reliability Engineering | Google (Beyer, Jones, Petoff, Murphy, eds.) | Running systems: SLOs and error budgets, monitoring, load balancing, handling overload and cascading failures | Staff candidates, and anyone whose deep dives keep ending at "what happens when it breaks"; free to read online |
| Web Scalability for Startup Engineers | Artur Ejsmont | Caching, queues, front-end and back-end scaling, explained from the ground up | Engineers new to building at scale |
Designing Data-Intensive Applications deserves its reputation. Chapters 5 to 9 (replication, partitioning, transactions, the trouble with distributed systems, consistency and consensus) are the theory behind most deep dives on this site. It does not teach you how to run an interview; read it alongside practice, not instead of it.
Books that walk through interview questions
| Book | Author | What it covers |
|---|---|---|
| System Design Interview: An Insider's Guide, volume 1 | Alex Xu | A four-step framework and the classic questions: rate limiter, consistent hashing, key-value store, unique IDs, URL shortener, web crawler, notifications, news feed, chat, autocomplete, YouTube, Google Drive |
| System Design Interview, volume 2 | Alex Xu and Sahn Lam | Harder questions: proximity service, nearby friends, Google Maps, message queue, metrics, ad click aggregation, hotel reservations, email, object storage, a real-time leaderboard, a payment system, a digital wallet, a stock exchange |
| Acing the System Design Interview | Zhiyong Tan | The interview process and non-functional requirements in depth, then worked questions |
| Machine Learning System Design Interview | Ali Aminian and Alex Xu | The ML round: recommendation, search ranking, ads, feeds and content moderation as ML systems |
These books show a finished answer to each question. What they cannot show is how a strong candidate gets there out loud: which questions to ask first, when to put numbers on the board, how to recover when the interviewer pushes on a weak spot. That part only comes from practice, which is what the walkthroughs and mock interviews on this site are for.
The papers behind the classic questions
Interviewers who ask you to design a key-value store usually have Dynamo in mind; a lock service, Chubby; a message queue, Kafka. Reading the original paper gives you the real trade-offs, and the vocabulary to name them.
| Paper | Year | What it teaches | Where it shows up |
|---|---|---|---|
| The Google File System (Ghemawat, Gobioff, Leung) | 2003 | A single metadata master, large chunks, replication, and designing for constant hardware failure | Object storage (S3), distributed file systems |
| MapReduce (Dean, Ghemawat) | 2004 | Batch processing over thousands of machines, with retries hiding failures | MapReduce and Spark, web crawler |
| Bigtable (Chang et al.) | 2006 | The wide-column model, tablets, and an LSM storage engine | Data modelling for Cassandra and DynamoDB |
| The Chubby lock service (Burrows) | 2006 | Coarse-grained locks, leases, sessions and a consensus group at the core | Distributed lock service, locks and leases |
| Dynamo (DeCandia et al.) | 2007 | Consistent hashing, sloppy quorums, hinted handoff, vector clocks and anti-entropy with Merkle trees | Key-value store, quorums |
| Cassandra (Lakshman, Malik) | 2009 | Dynamo's distribution combined with Bigtable's data model | Key-value store |
| Finding a needle in Haystack (Beaver et al.) | 2010 | Storing billions of photos by packing them into large files to save metadata lookups | Haystack, Instagram |
| ZooKeeper (Hunt et al.) | 2010 | A coordination service with ordered writes, watches and recipes for locks and leader election | Distributed lock service, consensus and coordination |
| Dapper (Sigelman et al.) | 2010 | Distributed tracing with sampling at low overhead | Distributed tracing |
| Kafka (Kreps, Narkhede, Rao) | 2011 | A partitioned, append-only log with consumers that track their own offsets | Message queue, how Kafka works |
| Spanner (Corbett et al.) | 2012 | Globally distributed transactions using TrueTime and bounded clock uncertainty | Spanner and distributed SQL |
| Scaling Memcache at Facebook (Nishtala et al.) | 2013 | A cache tier at very large scale: leases against thundering herds, regional pools, invalidation from the database | Distributed cache, caching |
| The Tail at Scale (Dean, Barroso) | 2013 | Why fan-out makes rare slowness common, and hedged requests to fix it | Tail latency, the tail latency playground |
| In Search of an Understandable Consensus Algorithm (Ongaro, Ousterhout) | 2014 | Raft: leader election, log replication and safety | How Raft works, the Raft playground |
Two older classics are worth an evening each: Lamport's "Time, Clocks, and the Ordering of Events in a Distributed System" (1978), the origin of logical clocks, and Gilbert and Lynch's 2002 proof of the CAP theorem.
How to read a paper for an interview
You are not reading to reproduce the paper. Read it for three things:
- The problem and the numbers. What load, what failure rate, what latency target forced the design? Interviewers reward numbers.
- The two or three key decisions and what they gave up. Dynamo chose availability over consistency and pushed conflict resolution to the application. Say the trade-off, not just the choice.
- What went wrong later. Many systems published a follow-up (Dynamo became DynamoDB with a different design). Knowing why shows judgement.
A page of notes per paper in that shape is worth more than a careful read of every section.
Engineering blogs
For questions about specific products, the companies' own engineering blogs are the most accurate public source: Netflix, Uber, Meta, Discord, Stripe, Cloudflare, Slack, Pinterest, Airbnb and LinkedIn all publish detailed write-ups of their systems. Read one or two posts about the system you are about to be asked about, and treat the details as one company's choice, not the answer.
A reading order for four weeks
- Week 1: one interview book, cover to cover, to learn the shape of an answer. Practise two questions out loud.
- Week 2: DDIA chapters 5 and 6 (replication and partitioning), then the Dynamo paper. Practise a key-value store and a cache.
- Week 3: DDIA chapters 7 to 9 (transactions, distributed systems, consistency), then Kafka and Raft. Practise a message queue and a payment system.
- Week 4: no new reading. Practise full rounds under a 45-minute clock.
The four-week study plan lays out the practice side of the same month.
Questions people ask
What is the best book for system design interviews?
For learning the shape of an interview answer, Alex Xu's System Design Interview: An Insider's Guide (volume 1) walks through a four-step framework and the classic questions. For the depth behind the deep dives, Designing Data-Intensive Applications by Martin Kleppmann is the single most useful book. Most candidates need one of each, then practice rather than more reading.
Is Designing Data-Intensive Applications enough for a system design interview?
No. It teaches how databases, replication, partitioning, transactions and stream processing really behave, which is the theory behind most deep dives, but it does not teach you how to run an interview. Read it alongside practice: one interview book for the shape of a 45-minute answer, and whole answers said out loud under a clock.
Which papers should I read for system design interviews?
Start with Dynamo, the clearest description of the trade-offs behind key-value stores and caches. Then Kafka for message queues, Raft for consensus, Chubby or ZooKeeper for coordination, The Tail at Scale for fan-out latency, and Scaling Memcache at Facebook for caching at scale. Read each for the problem and its numbers, the key decisions and what they gave up, and what went wrong later.
How should I read a research paper for an interview?
Read it for three things: the problem and the numbers that forced the design, the two or three key decisions and what each gave up, and what went wrong later or changed in a follow-up system. A page of notes per paper in that shape is worth more than a careful read of every section, because interviewers reward trade-offs and numbers.
How much should I read before practicing system design interviews?
Less than most candidates do. One interview book and a few chapters of Designing Data-Intensive Applications are enough to start practicing; reading more than three books is usually a way of avoiding practice. Spend the last week before the interview on full rounds under a 45-minute clock with no new reading.