Developer Knowledge
How to build a reading list for system design — a practical guide for engineers who want a structured, curated reading path for system design, from foundational concepts to advanced distributed systems, without spending weeks figuring out what to read and in what order.
System design is not a single topic. It's a cluster of related competencies: scalability, reliability, data modeling, distributed consensus, caching, messaging, storage engines, networking, and more. Learning these competencies requires reading across multiple books, academic papers, engineering blogs, and system design case studies — and the resources vary enormously in depth, focus, and prerequisite knowledge.
The challenge is not a shortage of material. The challenge is that the material is distributed, varies in quality, and has complex dependency relationships. Understanding Kafka's log-structured storage helps you understand why it's designed for high-throughput writes; understanding the Raft consensus algorithm helps you understand how Kafka's replication works; understanding CAP theorem provides the theoretical framework for understanding why Raft makes the tradeoffs it does. Without a structure, reading about system design can produce a collection of isolated facts without the mental models that make them useful.
A good reading list for system design provides: a coherent progression from foundational to advanced, explicit dependency relationships between resources, and enough specificity to make clear what each resource contributes that others don't.
System design knowledge builds in four levels, and the reading list should reflect this:
Level 1 — Foundational concepts: How computers work at the level that matters for system design. How TCP/IP works, what a database index is and why it exists, what a cache is and when to use one, what a message queue is and why you'd use it instead of direct service calls. Engineers who haven't internalized these concepts try to design systems with a gap in their mental model that leads to architectures that can't work.
Level 2 — Single-system depth: Deep understanding of one type of system: relational databases (how B-trees work, how transactions are implemented, what MVCC is), distributed key-value stores, message queues, or a specific type of networking infrastructure. This depth is what distinguishes an engineer who can design a system from one who can only follow a design.
Level 3 — Distributed systems theory: The theoretical framework: CAP theorem (Brewer, 2000), the Fallacies of Distributed Computing, consistency models (linearizability vs. eventual consistency), consensus algorithms (Paxos and Raft), vector clocks. These are the concepts that make the trade-offs in distributed system design legible — why Netflix does eventual consistency for their recommendation system but strong consistency for billing.
Level 4 — Real systems at scale: How actual systems — Google Bigtable, Amazon Dynamo, Facebook Haystack, Apache Kafka — are designed, what problems they solved, and what trade-offs they made. Engineering blog posts, architecture papers, and conference talks at this level.
The reading list should build from Level 1 upward, and each level's resources should explain why they make the choices they do (not just what those choices are).
"Designing Data-Intensive Applications" — Martin Kleppmann (O'Reilly, 2017) The single most important book for backend engineers learning system design. Covers: storage engines (how databases actually store data), distributed data, replication, partitioning, transactions, consistency, and batch and stream processing. Kleppmann is unusually clear about the trade-offs and the "why" behind each design choice. Not a light read; worth the investment.
"The System Design Interview" — Alex Xu (ByteByteGo, 2020) and "System Design Interview Vol. 2" (2022) A structured walk-through of how to approach common system design problems: URL shorteners, rate limiters, web crawlers, chat systems, news feeds. Less theoretical than Kleppmann but more immediately applicable to understanding how these systems are put together. Good for building a vocabulary and framework before going deeper.
"Computer Networks: A Top-Down Approach" — Kurose and Ross (8th ed., 2022) The standard undergraduate networking textbook. Heavy, but Chapters 1-3 (computer networks, application layer, transport layer) cover the foundational networking that system designers need: how TCP works, what DNS does, what HTTP/HTTPS are, how CDNs work. You don't need to read the whole book — read the chapters that address your specific gaps.
"Database Internals" — Alex Petrov (O'Reilly, 2019) Covers how database storage engines work at the implementation level: B-trees vs. LSM trees, write-ahead logs, concurrency control. Essential for engineers who work with databases daily and want to understand the trade-offs between different database designs. Kleppmann covers this conceptually; Petrov goes deeper mechanically.
"Kafka: The Definitive Guide" — Gwen Shapira, Todd Palino, Rajini Sivaram, and Krit Petty (O'Reilly, 2021, 2nd ed.) The comprehensive guide to Apache Kafka: its log-structured storage, consumer groups, partitioning model, exactly-once semantics, and stream processing. For engineers building event-driven systems, this is the primary reference. The first four chapters alone cover 90% of what most Kafka users need to understand.
"Redis in Action" — Josiah Carlson (Manning, 2013) Older but still accurate for understanding Redis's data structures and their appropriate use cases. The mental models for when to use strings vs. hashes vs. sorted sets vs. pub/sub are the core value. For engineers who use Redis without fully understanding why.
"Distributed Systems" — Maarten van Steen and Andrew Tanenbaum (4th ed., 2023, freely available at distributed-systems.net) The standard academic reference for distributed systems. More theoretical than the other resources; essential for engineers who want to understand the formal models behind consistency, replication, fault tolerance, and coordination. Not a cover-to-cover read for most engineers — use it as a reference when specific topics come up.
"Designing Distributed Systems" — Brendan Burns (O'Reilly, 2018) The Kubernetes co-creator's book on patterns for distributed systems: single-node patterns, serving patterns, batch computational patterns. More practical than theoretical; complements van Steen and Tanenbaum.
CALM Theorem and the "End of a Myth" papers: Joe Hellerstein and colleagues' work on coordination-freeness and monotonic computation. Available freely online. For engineers who want to understand when distributed systems can avoid coordination (and when they can't) at a theoretical level.
The Raft paper — Diego Ongaro and John Ousterhout, "In Search of an Understandable Consensus Algorithm" (2014) The original Raft paper, available freely at raft.github.io. Raft was designed to be more understandable than Paxos; the paper succeeds. Understanding Raft means understanding how distributed consensus actually works in systems like etcd, CockroachDB, and Kafka's KRaft mode.
"Bigtable: A Distributed Storage System for Structured Data" — Chang et al. (Google, 2006) The foundational paper for wide-column storage, available on Google Scholar. Bigtable's design influenced Cassandra, HBase, and many other systems. Understanding it makes all those systems more legible.
"Dynamo: Amazon's Highly Available Key-Value Store" — DeCandia et al. (Amazon, 2007) The foundational paper for eventually consistent distributed databases, available on the ACM DL. Dynamo's design choices — consistent hashing, vector clocks, eventual consistency — are in every modern distributed database. The "why" in the paper is as important as the "what."
"The Log: What every software engineer should know about real-time data's unifying abstraction" — Jay Kreps (LinkedIn Engineering Blog, 2013) Free on the LinkedIn Engineering Blog. Kreps' post on why the log data structure is fundamental to distributed systems is one of the most-cited pieces of writing in distributed systems engineering. 45 minutes; essential.
Highscalability.com: A curated collection of engineering blog posts and case studies about how specific systems were designed and scaled. The case studies section covers Netflix, Twitter, Airbnb, Uber, Stripe, and dozens more. Not a book; a browsable reference for specific system design patterns in production.
The canonical reading list above covers a lot of ground. Most engineers don't need all of it, and should build a personal list that reflects their specific gaps and goals.
Step 1: Identify your current level. For each topic area (storage, networking, distributed consensus, messaging, caching), assess honestly: do you have Level 1, 2, 3, or 4 knowledge? Where are your gaps?
Step 2: Identify what your role requires. If you primarily build CRUD applications on top of PostgreSQL and Redis, deep distributed consensus knowledge is interesting but not immediately high-return. If you're building infrastructure that other teams depend on, it's essential. Match reading to the knowledge that makes you more effective in your current and near-future role.
Step 3: Sequence for dependencies. Don't read Kleppmann's distributed data chapters before reading the single-node storage engine chapters — you'll lack the foundation. Don't read the Raft paper before understanding the problem it's solving (Byzantine fault tolerance vs. crash fault tolerance; what a leader election is for). Explicit sequencing prevents reading that doesn't land because the prerequisite mental models aren't in place.
Step 4: Mix reading types. Books for depth; engineering blogs for practical examples of how real companies implement concepts; academic papers for the original formulations of ideas. The three types complement each other: books provide the framework; blogs show the application; papers provide the theoretical precision.
A reading list that exists as a bookmark collection is less useful than a reading log that records not just what you read but what you took from it.
For each resource completed, record:
This is both a retrieval tool (searchable when you're looking for a specific concept) and a retention tool (articulating the core insight reinforces it).
Over time, a reading log also reveals patterns: areas where multiple resources have filled in a gap, areas where you keep noting "still don't understand the details," and areas where your reading has been thin despite relevance to your work.
A curated, sequenced reading list for system design converts the vast and disorganized landscape of system design literature into a structured learning path. The four-level progression — foundational concepts, single-system depth, distributed systems theory, real systems at scale — provides the sequencing; the specific resources at each level provide the depth. Building a personal reading list from the canonical list, matched to your specific gaps and role requirements, makes the investment targeted rather than comprehensive. The reading log that tracks what you learned from each resource is what converts reading into retained and retrievable knowledge.
More WebSnips articles that pair well with this topic.
How to build a knowledge base for a dev team — a practical guide for engineering teams who want a shared knowledge system that engineers actually use, that stays current as the team grows, and that reduces the time engineers spend re-answering the same questions.
How to document a microservices architecture — a practical guide for engineering teams navigating service sprawl, where the challenge is not documenting individual services but making the relationships, contracts, and operational behavior of a distributed system legible.
How to keep a changelog developers trust — a practical guide for engineering teams who want a CHANGELOG.md that consumers of their API or library actually read and rely on, rather than a dump of commit messages that obscures more than it reveals.
How to save and organize design docs — a practical guide for engineers and engineering teams who want their design documents to remain findable, useful, and connected to the decisions they documented, rather than accumulating in an untended archive.
How to take notes during code review — a practical guide for engineers who want to get more from code review than the immediate feedback loop: building a personal reference of patterns, anti-patterns, and architectural decisions accumulated across months of reviews.
How to track tech-debt decisions — a practical guide for engineering teams who want to manage their technical debt as intentional trade-offs rather than accumulated accidents, with a tracking system that makes debt visible, prioritizable, and repayable.