List: Papers Backend Engineers Should Read

Most “papers every engineer should read” lists are 50+ papers with no annotation. The reader opens the list, feels overwhelmed, bookmarks it, and never reads any. This list is different: 20 papers, annotated with what each one gives you that you can’t get from a blog post, grouped by the system design domain they inform. Explicit exclusions for popular papers that aren’t worth your time.

How this list is organized

Three principles:

1. Practical impact over historical importance. A paper is here if reading it changes how you design systems today — not because it was groundbreaking in 1985.
2. The 30-minute test. Every paper on this list delivers its core insight within the first 30 minutes of reading (roughly the first 8–10 pages). If a paper requires the full 30 pages to deliver value, it’s not here — a blog summary covers it.
3. Backend + AI stack. The list spans both classical distributed systems and the AI infrastructure layer, because that’s the stack backend engineers are building on now.

Papers are grouped by the design domain they’re most relevant to.

The list

Distributed storage and databases

• Dynamo: Amazon’s Highly Available Key-Value Store (2007) — Why: the vocabulary of modern distributed storage (consistent hashing, vector clocks, sloppy quorums, anti-entropy) originates here. Every system design interview that involves a KV store or a cache draws from this paper’s mental model. Read sections 1–4 and the system design table in §6.

• Bigtable: A Distributed Storage System for Structured Data (2006) — Why: the wide-column model (row key, column family, timestamp) and the LSM tree + SSTables storage engine that Cassandra, HBase, and LevelDB are all derived from. Read for the data model and compaction strategy. Skip the GFS dependency details.

• Spanner: Google’s Globally Distributed Database (2012) — Why: the only system that achieves external consistency (linearizability + serializability) at global scale, via TrueTime. The insight — using physical time as a synchronization primitive when clock uncertainty is bounded — is non-obvious and shapes how you think about consistency in global systems. Read sections 1–4.

• The Log-Structured Merge-Tree (O’Neil, 1996) — Why: the storage engine behind most modern write- heavy databases (Cassandra, RocksDB, LevelDB, HBase). Understanding write amplification, space amplification, and the compaction trade-off changes how you evaluate database choices. The paper is short.

Consensus and coordination

• In Search of an Understandable Consensus Algorithm (Raft) (2014) — Why: the consensus algorithm you can actually implement and reason about. Paxos is the original; Raft is the one you’d use in production (etcd, CockroachDB, TiKV all use Raft). Read the full paper — it’s designed to be understandable and it is.

• ZooKeeper: Wait-free Coordination for Internet-scale Systems (2010) — Why: the coordination-service model (linearizable writes, eventual reads, watches, ephemeral nodes) that inspired etcd and underpins Kafka, HBase, and most distributed systems’ cluster metadata. Read for the API model more than the implementation.

• Time, Clocks, and the Ordering of Events in a Distributed System (Lamport, 1978) — Why: the foundational reasoning about causality, happens-before, and logical clocks. Short, conceptually dense, and the reason we think about events the way we do. Every vector-clock and version-vector design traces back to this paper.

Streaming and data processing

• The Dataflow Model (2015) — Why: the unified model for batch and stream processing that Beam, Flink, and modern Spark Structured Streaming implement. If you’ve ever struggled with “when do I use batch vs stream?” this paper gives the answer: they’re the same computation model with different trigger policies. Read sections 1–3.

• Kafka: A Distributed Messaging System for Log Processing (2011) — Why: the log-as-infrastructure primitive. Kafka reframed message queues as durable, replayable logs — that insight (producers don’t care about consumers, consumers track their own offset) shapes every event-driven architecture you’ll build. Short paper; the design section is the valuable part.

Caching and load distribution

• Consistent Hashing and Random Trees (Karger et al., 1997) — Why: the algorithm behind every distributed cache, load balancer, and partitioned data store. The paper is more formal than you need — read the first 5 pages for the core idea; the rest is proofs. The Wikipedia article is a fine substitute if you want the idea without the math.

• Scaling Memcache at Facebook (2013) — Why: the practical reality of running a cache at billion-request scale. Thundering herds, lease-based invalidation, regional replication, and the insight that caching at scale is a consistency problem, not just a speed problem. Read for the failure modes more than the architecture.

Reliability and failure handling

• The Tail at Scale (Dean & Barroso, 2013) — Why: the insight that p99 latency at the component level becomes p50 latency at the system level when you fan out across many components. Hedged requests, tied requests, and “good enough” results are the mitigation patterns. Short and immediately applicable.

• Crash-Only Software (Candea & Fox, 2003) — Why: the design principle that software should only have one recovery path (crash and restart), not a separate “graceful shutdown” path. The argument is that if crash- recovery works, you never need graceful shutdown — and you’ve tested your recovery path on every restart. Short, contrarian, and shapes how you think about process management.

AI/ML infrastructure

• Attention Is All You Need (2017) — Why: the paper that defines the architecture behind every LLM you’ll ever serve. You don’t need to understand every equation, but understanding what multi-head attention does (and why it’s quadratic in sequence length) is the foundation for all inference optimization work. Read sections 1–3 and the architecture diagram.

• Efficient Memory Management for Large Language Model Serving with PagedAttention (2023) — Why: the paper behind vLLM and the dominant serving optimization in production. If you’re working on LLM inference — or designing systems that call LLMs — the KV cache memory management model in this paper is the binding constraint you need to understand. See the LLM serving walkthrough.

• Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks (2020) — Why: the paper that named the RAG pattern. The specific model architecture is less relevant now, but the framing — retrieval as a first-class component of generation, not an afterthought — shaped how every production RAG system is built. See the RAG walkthrough.

• Efficient and Robust Approximate Nearest Neighbor Search Using HNSW Graphs (2016) — Why: the algorithm behind every vector database’s primary index. If you’re building or using semantic search, you need the mental model of how HNSW works (multi-layer navigable graph, greedy traversal, O(log N) search). Read the first 8 pages. See the vector database walkthrough.

Unique ID generation and ordering

• Twitter Snowflake (2010) — Why: the dominant pattern for distributed ID generation (timestamp + worker_id + sequence). Not a paper per se, but the source code and README are the authoritative reference for how to generate unique, roughly-ordered IDs without coordination. Read the README and understand the bit layout.

System design meta

• Designing Data-Intensive Applications (Kleppmann, 2017) — Not a paper. A book. But it’s the single best synthesis of the papers on this list plus many others, organized by system design concern rather than by chronology. If you read one thing from this entire list, make it DDIA chapters 5, 6, 7, and 9. It’s the reason every other entry on this list is accessible.

What to skip

Popular papers that are frequently recommended but not worth your time given limited hours:

• MapReduce (Dean & Ghemawat, 2004). Historically important but operationally obsolete. Spark and Flink superseded it a decade ago. The idea (map → shuffle → reduce) is explained better in any intro to distributed computing than in the paper itself. Skip.
• Google File System (2003). Superseded by distributed object stores (S3, GCS). The paper’s insights about append-only writes and chunk replication are embedded in every modern storage system, but you get them better from the Bigtable and Dynamo papers. Skip.
• Paxos Made Simple (Lamport, 2001). Famously “simple” and famously not. Raft exists specifically because Paxos is too hard to implement correctly. Read Raft instead. Skip.
• CAP Theorem (Brewer, 2000/Gilbert-Lynch 2002). The theorem itself is trivially stated (choose 2 of 3). The nuance lives in PACELC and in real system trade-offs, not in the original paper. Read Kleppmann’s DDIA chapter 9 instead. Skip.
• Most papers about specific ML model architectures (ResNet, BERT, GPT-2/3/4, Llama). Unless you’re training models, the architecture details don’t help you design systems. Attention Is All You Need gives you the foundation; the rest is for ML researchers. Skip.
• Amazon Aurora (2017). Interesting but Amazon-specific implementation details. The insight (log-is-the-database) is covered better in blog posts. Skip unless you’re specifically working on Aurora.

How to use this list

If you have 3 months (one paper per week):

Read in this order: Raft → Dynamo → Lamport Clocks → Bigtable → Kafka → Tail at Scale → Scaling Memcache → Consistent Hashing → Attention Is All You Need → PagedAttention → HNSW → Dataflow Model. Skip Spanner, LSM-Tree, ZooKeeper, and the shorter ones (Crash-Only, Snowflake, RAG) — those are supplementary and can be read in 30 minutes each whenever relevant.

If you have 2 weeks:

Five papers: Dynamo, Raft, Tail at Scale, Attention Is All You Need, PagedAttention. This covers distributed storage, consensus, latency management, and the AI infrastructure layer.

If you have one weekend:

Raft + Dynamo + Tail at Scale. Three papers, ~4 hours of reading. This gives you the vocabulary for distributed systems, consistency, and latency that covers 80% of system design interview territory.

For all timeframes: read with a pen. Write one sentence per section summarizing the insight. The act of summarizing is what converts reading into understanding. A paper read passively in 30 minutes teaches less than one read actively in 60.

Related

• Framework: What’s Durable vs What’s Hype — the papers on this list are almost entirely in the “durable substrate” quadrant.
• Plan: 90-Day AI Ramp for Backend Engineers — the AI infrastructure papers (Attention, PagedAttention, HNSW, RAG) support Phase 1 of this ramp.
• Walkthrough: Designing a Distributed Cache — the Dynamo, Consistent Hashing, and Scaling Memcache papers are the lineage behind this walkthrough.

Date-stamped: written 2026-05-27. The classical distributed systems papers are timeless (Dynamo, Raft, Lamport). The AI papers (PagedAttention, HNSW) are current state-of-the-art as of 2026 — refresh the AI section annually as new foundational papers emerge.