7 resources↗
Use this collection after the fundamentals, consensus, and storage paths to explore design choices that cross those boundaries. Gray's economics paper and the data-engineering rules establish a cost-oriented way to reason about placement and caching; their numerical examples are historical, not present-day purchasing advice. The next papers examine ordering throughput and wide-area replication. Eventually consistent counters provide a focused replication problem, followed by Photon and Mesa as larger systems with demanding data-processing requirements. For each resource, identify the bottleneck, the mechanism introduced to address it, and the new constraint that mechanism creates. The sequence works well for a reading group because the papers invite concrete comparisons of assumptions and evaluation methods rather than agreement on one preferred architecture. Curated from collections by Dan Creswell (https://dancres.github.io/Pages/) and Fred Hébert (https://ferd.ca/a-distributed-systems-reading-list.html); commentary and reading order are original.
5 resources↗
Event ordering is a prerequisite for understanding replication conflicts, snapshots, and recovery. Lamport's paper establishes happens-before and explains how logical timestamps can support a total ordering. The dotted version vector examples then make causality concrete in a replicated key-value setting. Interval tree clocks extend the discussion to changing populations of participants, and the global-state survey connects local observations to consistent snapshots. Zab closes the sequence with ordering requirements in a primary-backup service. These resources belong together because they show different uses of ordering rather than presenting timestamps as a universal solution. Draw small executions with concurrent events and delayed messages, and ask what information each mechanism preserves or intentionally discards. Curated from collections by Dan Creswell (https://dancres.github.io/Pages/) and Fred Hébert (https://ferd.ca/a-distributed-systems-reading-list.html); commentary and reading order are original.
6 resources↗
Transaction guarantees are easiest to discuss when their scope and observable behavior are explicit. Start with an everyday service interaction that motivates asynchronous work and compensation. The PostgreSQL chapter provides concrete isolation terminology, but it is deliberately identified as historical version documentation. Strong consistency models helps distinguish ordering guarantees from transaction isolation before the HAT paper analyzes which transactional properties can coexist with high availability. Megastore and Spanner then provide two system-level case studies. This sequence suits engineers designing workflows that span records, services, or datacenters. Write a short concurrent execution for every guarantee you intend to require, and separate the atomicity of a business workflow from the semantics of an individual database transaction. Curated from collections by Dan Creswell (https://dancres.github.io/Pages/) and Fred Hébert (https://ferd.ca/a-distributed-systems-reading-list.html); commentary and reading order are original.
6 resources↗
Compare storage designs by starting with the workload and the guarantees each system must provide. GFS introduces a file-oriented design shaped by large data-processing jobs, and Bigtable builds a structured storage model for varied applications. Dynamo makes a useful contrast through its availability goals and treatment of conflicting versions. Megastore and Spanner bring transactional semantics into the comparison, while Mesa ends with the distinct needs of analytic data warehousing. Readers should already understand replication and basic consistency terminology. Build a comparison sheet covering partitioning, replication, failure recovery, and the responsibilities left to clients. The objective is to explain why a design fits its workload, rather than rank the papers as competing universal solutions. Curated from collections by Dan Creswell (https://dancres.github.io/Pages/) and Fred Hébert (https://ferd.ca/a-distributed-systems-reading-list.html); commentary and reading order are original.
7 resources↗
Follow a set of infrastructure problems from durable storage through batch computation, coordination, structured data, and interactive analysis. GFS and MapReduce establish an early storage-and-compute pairing. Chubby shows how a relatively small coordination service supports larger systems, and Bigtable illustrates the consequences for structured storage. Dremel and Percolator then address workloads that need a different execution model from large batch jobs. The Tail at Scale closes with responsiveness across a large service. These are historical design accounts, so read their workload assumptions and measurements in context. For each system, identify what it delegates to surrounding infrastructure and what it must guarantee itself. Together the papers explain useful relationships between components rather than a current inventory of Google's production stack. Curated from collections by Dan Creswell (https://dancres.github.io/Pages/) and Fred Hébert (https://ferd.ca/a-distributed-systems-reading-list.html); commentary and reading order are original.
6 resources↗
Start with the reasons software ends up distributed, then work through the consequences for latency, reliability, and service boundaries. These readings suit engineers who have built applications but want a firmer basis for decisions involving multiple machines. Waldo and Grigorik establish practical constraints. The end-to-end paper explains where guarantees belong, while Helland makes the boundary between local data and exchanged data explicit. Hamilton brings those ideas into deployment and operations, and Building on Quicksand closes with the uncertainty introduced by asynchronous recovery. Read in order, keeping one familiar service in mind. For each resource, write down an assumption your service makes about communication or failure and how you would test it. Curated from collections by Dan Creswell (https://dancres.github.io/Pages/) and Fred Hébert (https://ferd.ca/a-distributed-systems-reading-list.html); commentary and reading order are original.
5 resources↗
A timeout is an observation, and interpreting it requires assumptions about the system. Begin with a practical checklist of assumptions engineers commonly overlook, followed by Hamilton's operational perspective on recovery. The remaining papers make those assumptions precise: FLP establishes a limitation in the asynchronous crash-failure model, unreliable failure detectors show how additional information changes the problem, and Byzantine agreement considers participants that can send conflicting information. The reading order deliberately moves from operational questions to formal models. For each paper, record what processes and messages may do, which properties are guaranteed, and what is required for progress. Use those notes to distinguish an implementation defect from a guarantee the chosen model never offered. Curated from collections by Dan Creswell (https://dancres.github.io/Pages/) and Fred Hébert (https://ferd.ca/a-distributed-systems-reading-list.html); commentary and reading order are original.
5 resources↗
CAP is useful only when its definitions are clear. This sequence begins with a small illustrated argument, then adds Brewer's discussion of partition handling and recovery. The middle readings distinguish eventual consistency from stronger guarantees expressed through operation histories. The final paper asks what availability and convergence permit beyond the usual CAP slogan. Engineers comparing replicated databases should use the list to turn vague requirements into specific observations a client must be able to make. After each reading, sketch a two-replica example with delayed messages and state which outcomes are allowed. The progression moves from accessible explanation to formal research; the last resource deserves a slower reading than the first. Curated from collections by Dan Creswell (https://dancres.github.io/Pages/) and Fred Hébert (https://ferd.ca/a-distributed-systems-reading-list.html); commentary and reading order are original.
6 resources↗
Consensus connects a compact safety argument to a substantial amount of engineering. Begin with Raft's decomposition of a replicated log, then use Paxos Made Simple to isolate the problem of choosing a value. The original Paxos paper adds historical context and a fuller presentation. Paxos Made Live shows what implementing a dependable service required beyond the algorithm, while Zab provides another perspective on primary-backup broadcast and recovery. Reconfiguration finishes the sequence by changing the participants themselves. This is an intermediate-to-advanced path for readers comfortable with concurrency. Track safety, liveness, and failure assumptions separately, and draw a message trace before deciding that two protocols provide the same behavior. Curated from collections by Dan Creswell (https://dancres.github.io/Pages/) and Fred Hébert (https://ferd.ca/a-distributed-systems-reading-list.html); commentary and reading order are original.
5 resources↗
Distributed lookup separates a key from the machine that currently serves it. Begin with Chord's ring-based lookup, then compare the XOR metric used by Kademlia and the routing substrate provided by Pastry. Scribe demonstrates a service built on top of an overlay, making the relationship between routing and application behavior explicit. Dynamo closes the sequence by placing partitioning beside replication, versioning, and recovery in a storage service. The list is intended for readers comfortable with algorithms and network communication. Trace a lookup before and after a node joins or fails, then record what each design assumes about membership and communication. Focus on routing cost, resilience, and the work required when ownership changes. Curated from collections by Dan Creswell (https://dancres.github.io/Pages/) and Fred Hébert (https://ferd.ca/a-distributed-systems-reading-list.html); commentary and reading order are original.