On this page
The 10 must-read system design papers at a glance
The storage foundations
- The Google File System (GFS)
- MapReduce: processing at scale
- Bigtable: the wide-column blueprint
The availability papers
- Dynamo: the paper that launched a thousand NoSQL databases
- Cassandra: Dynamo meets Bigtable
Coordination and consensus
- The Chubby Lock Service
- Raft: consensus you can actually explain
Scale in practice
- HDFS: GFS for everyone
- Spanner: the CAP theorem, renegotiated
- The Log: the unifying abstraction
How to actually read a systems paper
What order should you read them in?
Do you need to read papers to pass a system design interview?
Common questions
Bottom line
Related questions
10 Must-Read System Design Papers for Engineers (2026)
On This Page
The 10 must-read system design papers at a glance
The storage foundations
- The Google File System (GFS)
- MapReduce: processing at scale
- Bigtable: the wide-column blueprint
The availability papers
- Dynamo: the paper that launched a thousand NoSQL databases
- Cassandra: Dynamo meets Bigtable
Coordination and consensus
- The Chubby Lock Service
- Raft: consensus you can actually explain
Scale in practice
- HDFS: GFS for everyone
- Spanner: the CAP theorem, renegotiated
- The Log: the unifying abstraction
How to actually read a systems paper
What order should you read them in?
Do you need to read papers to pass a system design interview?
Common questions
Bottom line
Related questions
Almost every pattern you use in a system design interview came from a research paper. Consistent hashing and eventual consistency come from Amazon's Dynamo paper. The wide-column model behind HBase and much of NoSQL comes from Bigtable. The coordination service you casually call "ZooKeeper" is a reimplementation of Google's Chubby. Reading the originals does something no summary can: it shows you the constraints the designers faced and the trade-offs they consciously made, which is exactly the kind of reasoning interviewers want to hear out loud.
This guide covers the ten system design papers genuinely worth your time in 2026. Every one is legally free to read, each section tells you what the paper actually teaches and what to take into your interview, and at the end you get a reading order so you do not have to work through all ten to benefit. Seven of the ten also have full deep-dive chapters in Grokking the System Design Interview II, so where a guided, lesson-by-lesson version of a paper exists, we link that too.
Quick answer: if you read only two, read Amazon's Dynamo paper for availability, consistent hashing, and eventual consistency, and Google's GFS paper for how to design storage around real workloads instead of textbook assumptions.
The 10 must-read system design papers at a glance
| # | Paper | Company, year | What it teaches |
|---|---|---|---|
| 1 | The Google File System | Google, 2003 | Designing storage around real workloads |
| 2 | MapReduce | Google, 2004 | Large-scale data processing on unreliable machines |
| 3 | Bigtable | Google, 2006 | The wide-column model behind modern NoSQL |
| 4 | Dynamo | Amazon, 2007 | Eventual consistency and consistent hashing |
| 5 | Cassandra | Facebook, 2009 | Combining Dynamo and Bigtable in one system |
| 6 | The Chubby Lock Service | Google, 2006 | Distributed coordination and locking |
| 7 | Raft | Stanford, 2014 | Consensus you can actually understand |
| 8 | HDFS | Yahoo, 2010 | The open-source descendant of GFS |
| 9 | Spanner | Google, 2012 | Global distribution with strong consistency |
| 10 | The Log | LinkedIn, 2013 | The abstraction behind Kafka and stream processing |
The storage foundations
1. The Google File System (GFS)
The GFS paper describes the distributed file system Google built to store the web. Its lasting lesson is not the architecture itself (a single master managing metadata, with data spread across ChunkServers) but the method: Google measured its real workload, noticed that files were huge, writes were mostly appends, and component failure was constant, and then designed for those facts instead of for the general case.
Interview takeaway: when you propose a storage design, justify it from the workload. "Reads dominate writes here, and most writes are appends, so..." is exactly the reasoning GFS models, and it is the difference between reciting an architecture and designing one.
If you want the paper decoded piece by piece, the GFS chapter of Grokking the System Design Interview II walks through the read, write, and append paths, the consistency model, and the criticisms that followed, ending with a mock interview on GFS itself.
2. MapReduce: processing at scale
The MapReduce paper introduced the programming model that made processing terabytes on thousands of cheap, failure-prone machines feel routine. It spawned Hadoop and an entire industry, and even though the tooling has moved on to Spark and successors, the core ideas (move computation to the data, make tasks idempotent so failures can be retried, let a scheduler handle stragglers) are permanent.
Interview takeaway: any time your design includes a batch job over large data, MapReduce vocabulary lets you explain how it survives worker failures without hand-waving.
3. Bigtable: the wide-column blueprint
The Bigtable paper describes Google's distributed storage for structured data: a sparse, sorted, multi-dimensional map partitioned into tablets, backed by GFS, with an LSM-style write path. HBase is a direct open-source implementation, and Cassandra borrowed its data model. If you have ever wondered why NoSQL databases love sorted keys and column families, this paper is the answer.
Interview takeaway: row-key design determines everything in wide-column stores. Bigtable teaches you to reason about key ordering, hot-spotting, and range scans, which comes up in almost every time-series or messaging design question. For a guided version, the Bigtable chapter in Grokking the System Design Interview II works through the data model, SSTables, tablets, and the read and write paths lesson by lesson.
The availability papers
4. Dynamo: the paper that launched a thousand NoSQL databases
Amazon's Dynamo paper is the single most interview-relevant paper ever written. Faced with a shopping cart that had to accept writes even during failures, Amazon chose availability over consistency and then engineered around the consequences: consistent hashing for partitioning, vector clocks for conflict detection, hinted handoff and read repair for recovery, and quorum tuning (N, R, W) to let each service pick its own trade-off.
Interview takeaway: half the standard system design vocabulary comes from this one paper. When an interviewer asks "what happens when a node dies" or "how do you handle conflicting writes," Dynamo gives you the precise mechanisms to answer with. We cover the underlying trade-offs in our guide to consistency patterns in distributed systems, and the Dynamo chapter in Grokking the System Design Interview II dedicates a lesson to each mechanism, from vector clocks to Merkle trees, ending with a Dynamo mock interview.
5. Cassandra: Dynamo meets Bigtable
The Cassandra paper describes how Facebook combined Dynamo's fully decentralized, always-writable architecture with Bigtable's richer data model to power inbox search. It is short, readable, and valuable precisely because it shows two prior papers being remixed to fit a new workload, which is the same synthesis skill interviews test.
Interview takeaway: Cassandra is the canonical "when to choose AP over CP" example. Being able to say why Facebook accepted eventual consistency for inbox search, and where you would not accept it, is a senior-level answer. The Cassandra chapter in Grokking the System Design Interview II goes deeper than the paper itself, covering consistency levels, the write and read paths, compaction, and tombstones.
Coordination and consensus
6. The Chubby Lock Service
Google's Chubby paper describes the coarse-grained lock and small-file service that GFS, Bigtable, and MapReduce all lean on for leader election and configuration. ZooKeeper and etcd are its direct descendants. The paper's quiet insight is organizational as much as technical: it is easier to give engineers a lock service than to make every team implement consensus correctly.
Interview takeaway: when your design needs leader election, distributed locks, or service discovery, Chubby is why the answer is "use a coordination service like ZooKeeper or etcd" rather than "implement Paxos in the application." The Chubby chapter in Grokking the System Design Interview II unpacks the design rationale, locks and sequencers, master election, and caching across fourteen lessons.
7. Raft: consensus you can actually explain
Consensus was long considered too hard to teach because Paxos, the original algorithm, is famously impenetrable. The Raft paper was explicitly designed for understandability, decomposing consensus into leader election, log replication, and safety. It worked: Raft now runs inside etcd, Consul, CockroachDB, and TiDB, and it is the version of consensus worth learning first.
Interview takeaway: you rarely need to recite a consensus algorithm in a product design interview, but understanding Raft lets you answer the follow-up questions that separate levels: what happens during a network partition, why an even number of replicas does not help, and why writes need a quorum.
Scale in practice
8. HDFS: GFS for everyone
The HDFS paper describes Yahoo's open-source implementation of the GFS ideas, built to store unstructured data reliably and stream it at high bandwidth. Reading it after GFS is instructive in a specific way: you see which of Google's decisions survived contact with a different organization and workload, and which were adapted.
Interview takeaway: HDFS block sizing, replication placement (one replica local, two on a remote rack), and NameNode as a single point of failure are all concrete talking points for any big-data storage question. The HDFS chapter in Grokking the System Design Interview II covers the read and write anatomy, fault tolerance, and the high-availability setup that addresses the NameNode problem.
9. Spanner: the CAP theorem, renegotiated
For years, "you cannot have global distribution and strong consistency" was a safe interview answer. Google's Spanner paper complicated it: by putting GPS receivers and atomic clocks in its datacenters (TrueTime), Google built a globally distributed database with externally consistent transactions. Spanner is the design behind Google Cloud Spanner and inspired CockroachDB.
Interview takeaway: Spanner is the sophisticated counterpoint to a naive CAP answer. "CAP still holds, but Spanner shows how far engineering can push the availability of a CP system" signals real depth, especially in senior interviews.
10. The Log: the unifying abstraction
Jay Kreps' essay The Log is technically a blog post rather than a peer-reviewed paper, and it earns its place here anyway. Written by Kafka's co-creator at LinkedIn, it shows how an append-only log unifies replication, change data capture, stream processing, and event sourcing. It is the conceptual foundation for every "design a real-time pipeline" question.
Interview takeaway: when your design includes Kafka, this essay is why. It gives you the language to explain ordering guarantees, replayability, and why a log beats a message queue for data integration. To see the ideas as a running system, the Kafka chapter in Grokking the System Design Interview II covers consumer groups, the controller broker, delivery semantics, and ZooKeeper's role.
How to actually read a systems paper
Research papers reward a different reading style than blog posts. A method that works:
- Read the abstract, introduction, and design sections. Skip the evaluation on the first pass. The benchmarks answer 2007's questions, not yours; the design reasoning is the durable part.
- Chase the "why" sentences. The most valuable lines explain why the obvious alternative was rejected. Those are your interview answers.
- Write a five-line summary from memory afterward. If you cannot state the problem, the key idea, and one trade-off, read the design section again.
- Connect each paper to a system you know. GFS to S3's design goals, Chubby to ZooKeeper, The Log to Kafka. Interviews reward the connection, not the citation.
What order should you read them in?
Interview in a few weeks: read Dynamo and skim Bigtable, then stop. Spend the remaining time practicing full designs, using our system design interview guide for the framework and the question patterns that actually come up.
A few months of runway: follow the lineage. GFS, MapReduce, and Bigtable first (they form one coherent story), then Dynamo and Cassandra as the availability counterpoint, then Chubby and Raft for coordination.
Going deep: all ten in the order listed, finishing with Spanner and The Log, which both assume the vocabulary the earlier papers build. Pair them with the free resources in our guide to the best free system design resources, especially MIT's distributed systems course, which uses several of these papers as its syllabus.
Do you need to read papers to pass a system design interview?
Honestly: no. Plenty of candidates pass without reading a single paper, and reading papers without practicing designs will not get you through a 45-minute interview. What the papers change is the quality of your reasoning under follow-up questions. A candidate who has read Dynamo does not say "use consistent hashing" as a memorized phrase; they can explain what breaks without it and what it costs.
The papers also do not give you a method: how to scope a vague question, structure the discussion, and manage the clock. That is what Grokking the System Design Interview teaches. And for the depth these papers point at, Grokking the System Design Interview II dissects seven of the ten systems on this list (Dynamo, Cassandra, Kafka, Chubby, HDFS, GFS, and Bigtable) chapter by chapter, with quizzes and a mock interview on each, so you get the papers' insights with the interview lens already applied.
Common questions
What are the best system design papers to read for interviews? Dynamo and Bigtable have the highest interview value per page: between them they cover consistent hashing, eventual consistency, quorums, LSM-based storage, and row-key design. Add GFS and Raft if you have more time.
Are these system design papers free to read? Yes, all ten. Google publishes its research papers freely, the Dynamo paper is hosted on Werner Vogels' own blog, Raft is at raft.github.io, and The Log is on LinkedIn's engineering blog. Every link in this article goes to a legal, free copy.
Should I read the Paxos paper or the Raft paper? Raft. It was written specifically to be understandable and it is what most modern systems (etcd, Consul, CockroachDB) actually implement. Read Paxos later only if consensus becomes a professional interest.
How many papers should I read before an interview? One or two, read well, beat ten skimmed. If your interview is close, read Dynamo carefully, connect it to a design question you have practiced, and spend the rest of your time doing mock designs rather than reading.
Are research papers better than courses for learning system design? They answer different questions. Papers teach you why the patterns exist; a structured course teaches you when and how to apply them in an interview. The strongest preparation stacks them: fundamentals and a framework first, papers for depth once the basics are automatic.
Bottom line
The ten papers above are the primary sources behind nearly everything in modern system design: GFS, MapReduce, and Bigtable for the Google storage lineage, Dynamo and Cassandra for availability, Chubby and Raft for coordination, HDFS and Spanner for scale in practice, and The Log for streaming. Read Dynamo first, follow the reading order that matches your timeline, and turn each paper into practiced answers rather than trivia. If ten is not enough and you want the full library, including the software architecture classics that this list leaves out, see 40 white papers for system design and software architecture, which groups them into eight themes with a reading plan. For the interview method itself, that is where Grokking the System Design Interview picks up exactly where the papers leave off.
Related questions
What our users say
Eric
I've completed my first pass of "grokking the System Design Interview" and I can say this was an excellent use of money and time. I've grown as a developer and now know the secrets of how to build these really giant internet systems.
MO JAFRI
The courses which have "grokking" before them, are exceptionally well put together! These courses magically condense 3 years of CS in short bite-size courses and lectures (I have tried Grokking System Design Interview, OODI, and Coding patterns). The Grokking courses are godsent, to be honest.
KAUSHIK JONNADULA
Thanks for a great resource! You guys are a lifesaver. I struggled a lot in design interviews, and Grokking System Design gave me an organized process to handle a design problem. Please keep adding more questions.
Access to 50+ courses
New content added monthly
Certificate of completion
$31.08
/month
Billed Annually
Recommended Course
Grokking the Object Oriented Design Interview
59,948+ students
3.9
Learn how to prepare for object oriented design interviews and practice common object oriented design interview questions. Master low level design interview.
View Course
