6 Distributed Systems

Distributed systems are presented as a discipline of explicit trade-offs. The chapter begins by showing how databases make promises about reliability and correctness through ACID: transactions should be all-or-nothing, preserve valid data states, avoid unsafe interference, and survive crashes once committed. It then expands from single-node reliability to distributed behavior, where CAP explains the unavoidable choice between consistency and availability during network partitions, while PACELC adds the everyday trade-off between consistency and latency even when the network is healthy. The chapter also introduces safety and liveness as a precise vocabulary for reasoning about correctness and progress.

A major focus is how distributed databases coordinate and expose data. Consensus is described as the mechanism that lets nodes agree on values, leaders, replication state, recovery decisions, and query results despite failures. Consistency models define what clients can observe across replicas, while isolation levels define how concurrent transactions interact inside a database. The chapter walks through the anomalies that weaker isolation can allow, including dirty writes, dirty reads, fuzzy reads, lost updates, read skew, write skew, and phantom reads, emphasizing that stronger isolation improves correctness but can reduce throughput. It also clarifies that “high availability” can mean different things, such as majority availability, total availability, or sticky availability, each with different implications for consistency, latency, and fault tolerance.

The second half shifts from database theory to practical system design patterns. Probabilistic increment reduces hot-row contention by trading exact counts for scalable approximations, while latency techniques focus on making systems faster, anticipating user actions, or improving perceived speed. Bloom filters show another useful trade-off: memory-efficient set membership checks with no false negatives but possible false positives. The chapter closes by distinguishing complicated systems, which can often be solved with repeatable methods, from complex systems, which require adaptation, experimentation, observability, controlled rollouts, simulation, collaboration, and sometimes machine learning. Overall, the chapter’s central lesson is that good distributed-system design depends on understanding which guarantees matter, what they cost, and when relaxing them is acceptable.

A bloom filter can return all the options except for false negatives.

Index 2 is set.

Index 0 is set.

Index 2 was already set.

Checking index 4.

Checking index 2.

Setting index 1 and 3.

Setting index 1 and 2.

Checking index 3 and 4.

• Databases — guarantees and trade-offs
• ACID defines the strongest reliability contract a single-node database typically offers: atomicity, consistency, isolation, and durability. Many distributed systems deliberately relax some of these properties for scalability or performance.
• CAP shows that under network partition, a distributed system must choose between consistency and availability — both is impossible. PACELC extends this with a second trade-off: even when there's no partition, the system must choose between latency and consistency.
• Safety properties guarantee that something bad won't happen; liveness properties guarantee that something good eventually will. Both are required in consensus algorithms, and they sometimes conflict.
• Consensus — getting distributed nodes to agree on a value despite failures — is the foundation underlying strong consistency, leader election, and reliable replication. Paxos and Raft are the canonical algorithms.
• Consistency models describe what clients can expect to observe across replicas. Isolation levels describe how concurrent transactions interact within a database. Both come in tiers, and stronger guarantees in either dimension cost performance.
• The seven canonical isolation anomalies — dirty writes, dirty reads, fuzzy reads, lost updates, read skew, write skew, and phantom reads — define the isolation hierarchy. Each level prevents a specific subset; serializability prevents all of them but at significant performance cost.
• Highly available is a vague term. The three precise availability models — majority available, totally available, and sticky available — each support different consistency trade-offs and suit different use cases.
• System design — patterns for distributed systems
• Probabilistic increment trades exactness for scalability: by incrementing by N with probability 1/N, we eliminate hot-row contention while keeping the count statistically accurate at scale.
• User-perceived latency can be reduced through three strategies: making the system faster, anticipating user actions and preloading work, and giving the illusion of speed. The last is often available even when the first two are exhausted.
• Bloom filters are memory-efficient probabilistic set-membership data structures. They guarantee no false negatives but allow false positives at a tunable rate. They're widely used in databases, CDNs, and blockchains to avoid expensive lookups for absent data.
• Complicated systems have repeatable solutions; complex systems require adaptive ones. Working effectively in complex environments calls for reversible decisions, careful metric choice, observability, simulation, and strong team collaboration.

FAQ