1·research.google
The Google File System
Why I added thisInspect how workload assumptions shape file layout, replication, and recovery.
A CURATED READING LIST
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.
Read at your own pace. Save this list to keep track of your progress.
1·research.google
Why I added thisInspect how workload assumptions shape file layout, replication, and recovery.
2·research.google
Why I added thisStudy the division of work between a simple programming model and a fault-tolerant runtime.
3·research.google
Why I added thisSee how applications use a coordination service and how actual usage changed its design.
4·research.google
Why I added thisMove from files to structured storage and examine the role of tablets and data layout.
5·research.google
Why I added thisContrast interactive queries over nested columnar data with batch processing.
6·research.google
Why I added thisStudy Percolator's use of transactions and notifications for incremental indexing.
7·research.google
Why I added thisFinish by considering why rare slow requests matter when a service fans out widely.
KEEP EXPLORING
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.
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.
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.