Vol 7: Distributed Systems

After a request times out, did the remote service miss it, keep working, or finish already? That awkward question leads into timing, consensus, replication, sharding, and the platforms and observations needed to run them. Adding machines gives you capacity and a longer list of suspects when something stops answering.

Prerequisites

• Understand processes, network requests, timeouts, and database transactions. Revisit Volume 3, Volume 4, and Volume 5 as needed.
• Learn basic container operations before the platform exercises; the Volume 0 Docker lab is a useful starting point. You do not need a Kubernetes cluster for the consensus and consistency chapters.

Coverage

Chapters 1–4 establish distributed models, RPC, consensus, and storage. Chapters 5–7 cover computation frameworks, microservices, and container platforms. Chapters 8–12 examine observation, reliability, infrastructure changes, and Kubernetes operations.

Chapter 1

• 1.1 Distributed System Model: Partial Failures, Timing, and the Impossibility Boundary
• 1.2 Time, Causality, and Consistency Models

Chapter 2

• 2.1 RPC and Serialization Contracts: Remote Calls Are Not Local Functions
• 2.2 Deadlines, Cancellation, Retries, and Streaming Backpressure

Chapter 3

• 3.1 Raft: Election, Log Replication, and Commit
• 3.2 Raft's Safe Reads, Membership Changes, and Snapshots

Chapter 4

• 4.1 Sharding and Replication: Where Is the Data Stored?
• 4.2 Leaderless Replication, Quorum, and Replica Repair
• 4.3 From HDFS to Spanner: Workload Determines Architecture

Chapter 5

• 5.1 MapReduce: Partitioning, Shuffle, and Failure Recovery
• 5.2 Spark: Lineage, DAG, DataFrame, and Data Skew

Chapter 6

• 6.1 Microservices Are Fault Topologies, Not Directory Splitting
• 6.2 Production Baselines for Microservice Platforms

Chapter 7

• 7.1 Container Runtime Mechanisms: Images, Isolation, Resources, and Lifecycle
• 7.2 Kubernetes: Declaring State and the Control Loop

Chapter 8

• 8.1 Observability Signals: From User Symptoms to System State
• 8.2 Instrumentation, Context Propagation, and Telemetry Pipelines

Chapter 9

• 9.1 SLI, SLO, and Error Budgets: Making Reliability a Decision-Making Tool
• 9.2 On-call, Incident Response, Postmortems, and Toil

Chapter 10

• 10.1 IaC: State, Dependency Graphs, and Safe Changes
• 10.2 GitOps: Continuous Reconciliation, Deployment, and Rollback

Chapter 11

• 11.1 Kubernetes Traffic Boundaries: Gateway API and NetworkPolicy
• 11.2 Kubernetes Stateful Workloads: Identity, Storage, and Recovery
• 11.3 Kubernetes Capacity Governance: Scheduling, Scaling, and Disruptions

Chapter 12

• 12.1 Metric Engineering: Cardinality, Histograms, and PromQL
• 12.2 Alerts and Diagnostic Dashboards: From Signal to Action
• 12.3 Active Observability and Observability as Code

Outcomes

• Draw the event sequence for a timeout, retry, or replica failure and state what the system guarantees under its assumptions.
• Compare consensus, replication, and sharding choices against consistency, availability, and access requirements.
• Choose observation signals and reliability targets, and assess the evidence for platform changes, capacity, and recovery.

How to use this map

For a first pass, complete Chapters 1–4 before collecting system names. If you already operate a cluster, bring a real failure to Chapters 7–12, then revisit the timing and consistency assumptions behind it. In each experiment, record where the failure occurs, which results are visible, and what recovery requires.