40 White Papers for System Design and Software Architecture

Almost every idea you use in a design discussion started in a paper. Consistent hashing, eventual consistency, the write-ahead log, the append-only log behind Kafka, the lock service you call ZooKeeper: each of them was first argued for in a document with a citation list. Reading the originals gives you something no summary provides, which is the constraint the authors were working under and the trade-off they knowingly accepted.

Most reading lists you find are a flat row of forty titles with a one-line blurb each. That is a bookmark dump, not a curriculum. This list is organized differently.

• The papers are grouped into eight themes, so you can read a theme and come away with a complete mental model instead of scattered facts.
• Every paper says what it teaches and what it changes about the way you design, not just what it is about.
• There is a suggested order, because a few of these are much harder than the rest and reading them first is how people give up.
• Every link is free and legal. No paywalls.
• Where Design Gurus has a guided, lesson-by-lesson version of a paper, it is linked next to the paper.

If you want a much shorter starting point, the 10 must-read system design papers covers the essential subset with longer summaries of each. This article is the complete library.

The 40 Papers at a Glance

How to Read a System Design Paper

Reading a paper front to back like a textbook is the slowest way to get value from it, and it is why most people quit after two. Use three passes instead.

Pass one, ten minutes. Read the abstract, the introduction, the section headings, and the conclusion. Skip everything else. At the end, you should be able to say what problem the paper solves and roughly how. If you cannot, the paper is either above your current level or not worth your time yet.

Pass two, one hour. Read the body, but skip proofs, formal notation, and evaluation graphs. Copy the main architecture diagram onto paper by hand. Write one sentence for each component describing what it owns.

Pass three, only for the papers you care about. Read the evaluation section and ask why they measured what they measured. Read the "related work" and "limitations" sections, which is where the authors admit what the design cannot do.

Then ask four questions of every paper. What was the workload the authors measured before designing? Which property did they give up, and why was that acceptable? What breaks when a component fails? What would you have to change if the scale were ten times smaller, which is almost always your real situation?

Those four questions are the same ones a good interviewer asks. Practicing them on papers is direct interview preparation, which is why this reading habit pays off twice.

Start Here: Five Papers That Change How You Think

These five are short, mostly free of heavy math, and each one rewires an assumption. Read them in this order before anything else on the list.

1. End-to-End Arguments in System Design

Read the paper (Saltzer, Reed, and Clark, 1984). The argument is that a function such as reliable delivery or encryption often cannot be completed correctly by the lower layers of a system, so it must be implemented at the endpoints, and putting it in the lower layers is at best an optimization. Once you internalize this, a whole class of design questions answers itself: where retries belong, why TCP does not make your application reliable, and why deduplication ends up in your handler rather than in your queue.

2. Hints for Computer System Design

Read the paper (Butler Lampson, 1983). This is a collection of design heuristics from someone who had already built a lot of systems: keep it simple, do one thing well, handle the normal case fast and the worst case correctly, use hints rather than guarantees where you can. It reads like a senior engineer talking, and it is probably the single highest value-per-page document on this list.

3. Time, Clocks, and the Ordering of Events in a Distributed System

Read the paper (Leslie Lamport, 1978). It establishes that in a distributed system there is no shared "now", defines the happens-before relation, and introduces logical clocks. Every conversation you will ever have about event ordering, causality, and conflict resolution traces back to this. The guided version of the follow-on idea is the Vector Clocks lesson.

4. Brewer's Conjecture and the Feasibility of Consistent, Available, Partition-Tolerant Web Services

Read the paper (Gilbert and Lynch, 2002). This is the formal proof of the CAP theorem, and reading it cures the most common interview mistake about CAP, which is treating it as a menu where you pick two. Partitions are not optional, so the real choice is what to do during one. The CAP Theorem lesson covers the interview-ready version.

5. A Note on Distributed Computing

Read the paper (Waldo, Wyant, Wollrath, and Kendall, 1994). The paper attacks the idea that remote calls can be made to look like local calls. Latency, partial failure, and concurrency do not go away because a framework hides them. If your team is arguing about whether to split a service, this paper is the argument for why the network is a design decision and not a deployment detail.

Software Architecture Classics

Distributed systems papers get all the attention, but architecture questions in interviews and in real jobs are usually about coupling, boundaries, and complexity. These four are the canon.

6. On the Criteria To Be Used in Decomposing Systems into Modules

Read the paper (David Parnas, 1972). Parnas takes one small program, decomposes it two ways, and shows that splitting by processing steps produces a system where every change touches every module, while splitting by hidden design decisions produces one where changes stay local. This is the original argument for information hiding, and it is still the best answer to "how should I split this service?"

7. No Silver Bullet: Essence and Accidents of Software Engineering

Read the paper (Fred Brooks, 1986). Brooks separates essential complexity, which comes from the problem itself, from accidental complexity, which comes from our tools and choices. His claim was that no single technique would deliver an order-of-magnitude gain, because the essential part is what dominates. It is the sharpest available lens for evaluating whether a new framework will actually help you.

8. Out of the Tar Pit

Read the paper (Moseley and Marks, 2006). The argument is that most complexity in large systems comes from mutable state and control flow rather than from the problem domain, and the paper proposes separating the essential state, essential logic, and accidental parts of a system. Read it before your next debate about caching layers and duplicated state across services.

9. Big Ball of Mud

Read the paper (Foote and Yoder, 1997). A structured, honest description of the most common architecture in the world: the system with no discernible structure at all. It explains the forces that produce mud, including deadlines and turnover, and it names the patterns that let teams live with it. Read it as a warning label rather than as advice.

Storage and File Systems

10. The Google File System

Read the paper (Google, 2003). GFS stores enormous files across cheap machines with a single master for metadata and chunk servers for data. The lasting lesson is the method, not the architecture: Google measured its own workload, found that files were huge, writes were mostly appends, and failure was constant, then designed for those facts instead of for the general case. Guided version: Google File System.

11. The Hadoop Distributed File System

Read the paper (Yahoo, 2010). HDFS is the open-source reimplementation of the GFS ideas, and it is worth reading right after GFS because it shows which design choices survived contact with a different organization and which ones changed. It is also the clearest description of the metadata bottleneck a single-master design creates. Guided version: HDFS.

12. Finding a Needle in Haystack: Facebook's Photo Storage

Read the paper (Facebook, 2010). A general-purpose file system spends too many disk operations on metadata when you have billions of small photos, so Facebook packed many photos into large files and kept a compact index in memory. If your interview question involves images, videos, or attachments, this is the paper that tells you what the storage tier should look like.

13. Windows Azure Storage

Read the paper (Microsoft, 2011). One system that serves blobs, tables, and queues on a shared stream layer, with strong consistency and a clean separation between the stream layer and the partition layer. It is the best available description of how a commercial cloud storage service is actually put together.

14. The Log-Structured Merge-Tree

Read the paper (O'Neil et al., 1996). The LSM tree turns random writes into sequential ones by buffering in memory and merging sorted files on disk. Every write-optimized store you name in an interview, including Cassandra, RocksDB, and HBase, is built on it, and understanding compaction is what lets you answer follow-up questions about write amplification and read latency. The related pattern lesson is Write-Ahead Log.

Databases, Replication, and Partitioning

15. Bigtable: A Distributed Storage System for Structured Data

Read the paper (Google, 2006). Bigtable introduced the sparse, sorted, multidimensional map that became the wide-column model, along with tablets, SSTables, and the split between a coordination service and the data path. It is the most direct ancestor of HBase and a strong influence on Cassandra. Guided version: BigTable.

16. Dynamo: Amazon's Highly Available Key-value Store

Read the paper (Amazon, 2007). Dynamo is the paper that made availability-first design respectable: consistent hashing for placement, vector clocks for conflict detection, quorums for tunable consistency, and a shopping cart that never refuses a write. If you read only one paper on this entire list, read this one. Guided version: Dynamo.

17. Cassandra: A Decentralized Structured Storage System

Read the paper (Facebook, 2009). Cassandra takes Dynamo's ring and gossip and puts Bigtable's data model on top of it. Reading it directly after the other two is the cheapest way to see how two independent designs compose, and it is short. Guided version: Cassandra.

18. Spanner: Google's Globally Distributed Database

Read the paper (Google, 2012). Spanner provides externally consistent transactions across continents by making clock uncertainty explicit with the TrueTime API and waiting it out. The idea worth carrying into an interview is that you can buy consistency with latency, and that being honest about uncertainty is better than pretending it does not exist.

19. Amazon Aurora: Design Considerations for High Throughput Cloud-Native Relational Databases

Read the paper (Amazon, 2017). Aurora's central move is that the log is the database: only redo log records cross the network, and the storage layer materializes pages. It is the clearest modern example of redesigning a familiar component around the network being the bottleneck.

20. Consistent Hashing and Random Trees

Read the paper (Karger et al., 1997). The original consistent hashing paper, written for web caching rather than for databases. Read it to understand why adding a node moves only a small fraction of keys, and why virtual nodes exist. Guided version: Consistent Hashing.

Consensus and Coordination

21. Paxos Made Simple

Read the paper (Leslie Lamport, 2001). Lamport's own attempt to explain Paxos in plain terms, and still difficult, which is the point: agreement among machines that can fail and messages that can be lost is genuinely hard. Read it for the shape of the problem rather than to memorize the protocol.

22. Paxos Made Live: An Engineering Perspective

Read the paper (Google, 2007). The engineers who built Chubby describe everything the algorithm papers leave out: disk corruption, master leases, membership changes, and the sheer volume of code that a one-page algorithm turns into. This is the paper that teaches you the distance between a correct algorithm and a running system.

23. In Search of an Understandable Consensus Algorithm (Raft)

Read the paper (Ongaro and Ousterhout, 2014). Raft was designed to be teachable, splitting consensus into leader election, log replication, and safety. If you need to explain a replicated state machine on a whiteboard, explain Raft, not Paxos. The pattern behind it appears in the Leader and Follower chapter of the Advanced course.

24. The Chubby Lock Service for Loosely Coupled Distributed Systems

Read the paper (Google, 2006). Chubby packages consensus behind a familiar file-and-lock interface so that ordinary services can use it without implementing Paxos. The insight to take away is about interface design: most teams need coarse-grained locks and a small amount of reliable metadata, not a consensus library. Guided version: Chubby.

25. ZooKeeper: Wait-free Coordination for Internet-scale Systems

Read the paper (Yahoo, 2010). ZooKeeper offers a wait-free API with ordering guarantees, and shows that you can build locks, leader election, and group membership on top of those primitives rather than shipping them as blocking operations. Read it next to Chubby to compare two answers to the same question.

Data Processing and Streaming

26. MapReduce: Simplified Data Processing on Large Clusters

Read the paper (Google, 2004). Two functions, a shuffle in the middle, and a runtime that handles failure, stragglers, and locality. The programming model matters less now than the runtime lessons do: re-execution as the failure strategy, and speculative execution for slow tasks.

27. Kafka: A Distributed Messaging System for Log Processing

Read the paper (LinkedIn, 2011). The original Kafka paper is short and pragmatic: a partitioned, append-only log with consumer-tracked offsets and no per-message state on the broker. Understanding why the broker does so little is what lets you answer questions about ordering, replay, and consumer groups. Guided version: Kafka.

28. Resilient Distributed Datasets (Spark)

Read the paper (Berkeley, 2012). RDDs recover from failure by recomputing from lineage instead of replicating data, which is what made in-memory cluster computing affordable. The transferable idea is that remembering how you produced something can be cheaper than storing copies of it.

29. MillWheel: Fault-Tolerant Stream Processing at Internet Scale

Read the paper (Google, 2013). MillWheel shows how to get exactly-once effects in a streaming system using persistent state, low watermarks, and record deduplication. If you have ever claimed "exactly-once" in an interview, this paper tells you what you were actually promising.

30. The Dataflow Model

Read the paper (Google, 2015). This is the paper that unified batch and streaming into one model of windows, triggers, and watermarks, and it is the foundation of Apache Beam and of modern Flink semantics. Read it when late-arriving data starts to matter in your designs.

Performance and Reliability at Scale

31. The Tail at Scale

Read the paper (Dean and Barroso, 2013). When a request fans out to hundreds of servers, the slowest response defines the user experience, so rare slowness becomes common at the tail. The paper's techniques, including hedged requests and tied requests, are the correct answer whenever an interviewer asks how you would improve p99 latency.

32. Large-scale Cluster Management at Google with Borg

Read the paper (Google, 2015). Borg is the system Kubernetes descends from, and the paper is candid about what worked and what did not, including the value of separating jobs by priority and the operational pain of quota. Read it if you want to speak credibly about scheduling, bin packing, and resource isolation.

33. Scaling Memcache at Facebook

Read the paper (Facebook, 2013). This is the best paper on caching as a distributed system rather than as a library call: lease-based stampede control, regional pools, cold cluster warmup, and cross-region invalidation. Almost every caching follow-up question in an interview is answered somewhere in this paper.

34. Dapper: A Large-Scale Distributed Systems Tracing Infrastructure

Read the paper (Google, 2010). Dapper introduced the trace and span model that OpenTelemetry uses today, along with the sampling strategy that makes tracing affordable. If your design answer includes microservices, this is the paper that explains how anyone debugs them.

35. TAO: Facebook's Distributed Data Store for the Social Graph

Read the paper (Facebook, 2013). TAO is a read-optimized graph store layered over sharded databases and a cache tier, built because a general-purpose cache could not express the association queries a social graph needs. It is the reference answer for any "design a feed, a friends list, or a follow graph" question.

Modern Systems Worth Reading Now

36. Amazon DynamoDB: A Scalable, Predictably Performant, and Fully Managed NoSQL Database Service

Read the paper (Amazon, 2022). Fifteen years after the Dynamo paper, this one describes what running the managed service taught them: predictable performance matters more to customers than peak throughput, and most of the engineering goes into isolation, admission control, and avoiding noisy neighbors. Read it directly after Dynamo for the before-and-after effect.

37. Zanzibar: Google's Consistent, Global Authorization System

Read the paper (Google, 2019). Zanzibar stores relationship tuples and answers "can this user do this thing" globally within milliseconds, using a consistency token to avoid the new-enemy problem. Permissions questions appear in interviews far more often than the reading lists suggest, and this is the definitive treatment.

38. The Snowflake Elastic Data Warehouse

Read the paper (Snowflake, 2016). The paper that made separating storage from compute the default expectation for analytics: data lives in object storage, compute clusters come and go, and metadata is the coordination point. The architecture is now copied so widely that it is worth reading the original argument.

39. Delta Lake: High-Performance ACID Table Storage over Cloud Object Stores

Read the paper (Databricks, 2020). Object storage gives you durability and no transactions, and Delta Lake adds a transaction log on top so that readers see consistent snapshots. This is the paper behind the lakehouse idea and a good example of building a strong guarantee out of a weak primitive.

40. Efficient Memory Management for Large Language Model Serving with PagedAttention

Read the paper (Berkeley, 2023). The vLLM paper applies operating system paging to the key-value cache of a language model and multiplies serving throughput. It is on this list because AI serving questions are now standard, and because it is a beautiful example of an old idea moving to a new domain. If those questions are on your interview loop, Grokking the AI System Design Interview covers the surrounding material.

A Reading Plan That People Finish

Forty papers at one per week is a year of work, and almost nobody completes it. Here is a schedule that produces most of the benefit in three months.

Weeks 1 to 2, the mental models. Papers 1 through 5. Short, argumentative, and they change how you read everything after.

Weeks 3 to 4, the architecture canon. Papers 6 through 9. Read one per week and apply it to a system you actually work on.

Weeks 5 to 7, storage and databases. GFS, Bigtable, Dynamo, then Cassandra. This is the classic sequence, and each paper makes the next one easier.

Weeks 8 to 9, coordination. Raft first, then Chubby, then Paxos Made Live. Read Paxos Made Simple only after Raft, or it will discourage you.

Weeks 10 to 11, data in motion. MapReduce, Kafka, and either the Dataflow Model or MillWheel depending on whether your work involves streams.

Week 12, production reality. The Tail at Scale and Scaling Memcache. Both are immediately useful the next time something is slow.

The remaining papers are reference material. Read them when a real problem or a specific interview makes one of them relevant, which is when they will stick anyway.

Which Papers Map to Which Interview Questions

Papers pay off in interviews only if you can connect them to a design question. This table is the mapping worth memorizing.

For the interview framework that sits on top of all of this, use Grokking the System Design Interview, and for the paper-by-paper deep dives, the Advanced System Design Interview turns seven of these papers into guided chapters with quizzes and mock interviews.

Frequently Asked Questions

Are white papers worth reading for a system design interview? Selectively, yes. Nobody will ask you to recite a paper, but candidates who have read Dynamo and the Tail at Scale reason differently: they name trade-offs instead of listing components. Five papers read carefully will help you more than forty skimmed.

Which paper should I read first? Hints for Computer System Design if you want practical judgment, or Dynamo if you have an interview coming up. Both are readable in one sitting.

Do I need to understand the proofs and the math? No. Skip the formal sections on the first two passes. The design reasoning, the failure handling, and the evaluation are where the value is for engineers.

These papers are decades old. Are they still relevant? The hardware changed and the constraints did not. Networks still partition, clocks still drift, and machines still fail independently. Papers 36 through 40 cover what actually changed, which is mostly the economics of storage and the arrival of managed services.

How long does one paper take? Ten minutes for pass one, about an hour for pass two. Budget two hours for the harder ones such as Spanner or Paxos.

Should I read papers or take a structured course? Do both, in the right order. Learn the vocabulary first, otherwise papers are slow and frustrating. Grokking System Design Fundamentals covers the building blocks, and papers then give you the reasoning behind them.

Where can I find these papers for free? Every link on this page is a free, legal copy hosted by the authors, their institutions, or the conference that published the paper. No account is required for any of them.

What to Do With All of This

Papers are not a badge. They are a way to borrow the reasoning of people who solved a problem at a scale you have not reached yet, and the borrowing only works if you convert what you read into something you can say out loud.

So finish each paper with three sentences written in your own words: what problem it solved, what it gave up, and where you would use the idea. Do that for the twelve papers in the reading plan and your design conversations change noticeably.

When you want the guided path, start with Grokking System Design Fundamentals for the building blocks, then Grokking the System Design Interview for the framework and the classic questions. The shorter version of this reading list, with longer summaries of the ten essential papers, is in 10 must-read system design papers.