10 Must-Read System Design Papers for Engineers (2026)
10 Must-Read System Design Papers for Engineers (2026)
Arslan Ahmad
July 4th, 2026
The system design research papers actually worth your time in 2026: what each one teaches, the order to read them in, free links to every paper, and how to turn them into interview answers.
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.
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.
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.
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.
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.
Interview takeaway: when your design needs leader election, distributed locks, or service discovery, use a coordination service like ZooKeeper or etcd.
7. Raft: consensus you can actually explain
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.
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.
Interview takeaway: HDFS block sizing, replication placement, and NameNode as a single point of failure are all concrete talking points for any big-data storage question.
9. Spanner: the CAP theorem, renegotiated
Google's Spanner paper complicated the idea that one cannot have global distribution and strong consistency.
Interview takeaway: Spanner shows how far engineering can push the availability of a CP system.
10. The Log: the unifying abstraction
Jay Kreps' essay The Log shows how an append-only log unifies replication, change data capture, stream processing, and event sourcing.
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.
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.
- Chase the "why" sentences.
- Write a five-line summary from memory afterward.
- Connect each paper to a system you know.
What order should you read them in?
Interview in a few weeks: read Dynamo and skim Bigtable.
A few months of runway: follow the lineage.
Going deep: all ten in the order listed.
Do you need to read papers to pass a system design interview?
Honestly: no. The papers also do not give you a method: how to scope a vague question, structure the discussion, and manage the clock.
Common questions
What are the best system design papers to read for interviews?
Are these system design papers free to read?
Should I read the Paxos paper or the Raft paper?
How many papers should I read before an interview?
Are research papers better than courses for learning system design?
Bottom line
The ten papers above are the primary sources behind nearly everything in modern system design: GFS, MapReduce, Dynamo, Spanner, and The Log. Read Dynamo first, follow the reading order that matches your timeline, and turn each paper into practiced answers rather than trivia.