Distributed Systems Core Concepts Cheat Sheet

Updated 2026-05-28

Next Topic: Domain-Driven Design (DDD) Cheat Sheet

🧠Study flashcards on this topic152 cards · spaced repetition→

Distributed systems enable computation and data storage across multiple independent nodes that coordinate to appear as a single coherent system, powering everything from cloud databases and microservices to content delivery networks and blockchain platforms. As systems scale beyond single machines and geographic boundaries, understanding the fundamental tradeoffs — between consistency, availability, partition tolerance, and latency — becomes critical for architects building resilient global infrastructure. The key mental model: every distributed system is a collection of tradeoffs, not a collection of solutions, and mastering these tradeoffs is what separates reliable production systems from fragile ones.

What This Cheat Sheet Covers

This topic spans 20 focused tables and 158 indexed concepts, 152 flashcards. Below is a complete table-by-table outline of this topic, spanning foundational concepts through advanced details.

Table 1: CAP Theorem and Fundamental TradeoffsTable 2: Consistency ModelsTable 3: Consensus AlgorithmsTable 4: Time and Ordering in Distributed SystemsTable 5: Distributed TransactionsTable 6: Replication StrategiesTable 7: Data Partitioning and ShardingTable 8: Failure Detection and RecoveryTable 9: Conflict Resolution StrategiesTable 10: Gossip and Epidemic ProtocolsTable 11: Coordination and Distributed LockingTable 12: Distributed Hash TablesTable 13: Quorum SystemsTable 14: Data Integrity and VerificationTable 15: Message Delivery SemanticsTable 16: Broadcast PrimitivesTable 17: Retry and Resilience PatternsTable 18: Advanced ConceptsTable 19: Load Balancing StrategiesTable 20: Service Discovery Patterns

Quick IndexSubscribe to unlock

A jump-to index of every table row in this cheat sheet.

Mind MapSubscribe to unlock

An interactive map of every table and concept in this topic.

Table 1: CAP Theorem and Fundamental Tradeoffs

The CAP theorem is the starting point for reasoning about any distributed system, but PACELC extends it by addressing the latency-consistency tradeoff that occurs even in the absence of network partitions — which is the more common operating condition. Understanding BASE versus ACID, and knowing which quadrant a system occupies in the PACELC taxonomy, directly drives architectural decisions.

Concept	Example	Description
CAP Theorem	Choose 2 of 3: C+P, A+P	Only two of three guarantees simultaneously possible when a network partition occurs: Consistency, Availability, Partition Tolerance.
PACELC Theorem	PA/EL (Cassandra) vs PC/EC (Spanner)	• Extends CAP: during Partition → choose A vs C; Else → choose L (Latency) vs C (Consistency) • more practical than CAP for normal operations.
Consistency (CAP)	All nodes see same data at same time	• Every read receives the most recent write or an error • all replicas must agree before responding
Availability (CAP)	Every request gets non-error response	• System responds to every request even if some nodes are down • may return stale data during partition
Partition Tolerance (CAP)	System continues despite network split	System operates correctly even when network messages are lost or delayed between nodes.
ACID Properties	Traditional relational transactions	• Atomicity: all-or-nothing • Consistency: valid state transitions • Isolation: concurrent execution safety • Durability: persisted writes survive failures.
BASE Properties	DynamoDB, Cassandra	• Basically Available: responds even if inconsistent • Soft state: may change without input • Eventually consistent: converges over time.
CP Systems	etcd, Consul, ZooKeeper	• Prioritize Consistency and Partition tolerance • become unavailable during network partition to preserve consistency.
AP Systems	Cassandra, DynamoDB, Riak	• Prioritize Availability and Partition tolerance • remain available during partition but may return stale data.
Two Generals' Problem	Can't guarantee mutual commit over lossy channel	• Proves impossibility of reaching guaranteed consensus over an unreliable communication channel • motivates Saga, Outbox, and idempotency patterns

Table 2: Consistency Models

Consistency models form a spectrum from strongest (linearizability) to weakest (eventual consistency); choosing the right level requires balancing correctness guarantees against latency and availability costs. The session-level guarantees — read-your-writes, monotonic reads, monotonic writes — are often sufficient for user-facing applications without the cost of global strong consistency.

Model	Example	Description
Linearizability	`read(x) → 5` immediately after `write(x, 5)`	• Strongest consistency — operations appear atomic at a single point in time • real-time ordering preserved across all nodes.

The rest of this section is part of the full cheat sheet

Table 3: Consensus Algorithms

Consensus is the mechanism by which distributed nodes agree on a single value despite failures; it is the theoretical foundation of leader election, replicated state machines, and distributed databases. The key insight of FLP Impossibility is that pure asynchronous consensus is impossible, which is why all practical algorithms use timeouts or randomization.

Algorithm	Example	Description
Raft	etcd, Consul, TiKV	• Understandable alternative to Paxos: strong leader, log replication, term-based elections • explicitly designed for implementability

The rest of this section is part of the full cheat sheet

Table 4: Time and Ordering in Distributed Systems

Without a global clock, distributed systems cannot determine which event happened first unless they use logical or hybrid clocks to impose order based on causality. The fundamental problem — nodes have independent clocks that drift — means time-based ordering is inherently probabilistic unless hardware-assisted mechanisms like TrueTime are used.

Concept	Example	Description
Lamport Timestamps	Counter increments: $C_i = C_i + 1$	• Logical clock assigning scalar values to events • captures happened-before relation • if $a \to b$ then $C(a) < C(b)$.

The rest of this section is part of the full cheat sheet

Table 1: CAP Theorem and Fundamental Tradeoffs

Concept	Example	Description
CAP Theorem	Choose 2 of 3: C+P, A+P	Only two of three guarantees simultaneously possible when a network partition occurs: Consistency, Availability, Partition Tolerance.
PACELC Theorem	PA/EL (Cassandra) vs PC/EC (Spanner)	• Extends CAP: during Partition → choose A vs C; Else → choose L (Latency) vs C (Consistency) • more practical than CAP for normal operations.
Consistency (CAP)	All nodes see same data at same time	• Every read receives the most recent write or an error • all replicas must agree before responding
Availability (CAP)	Every request gets non-error response	• System responds to every request even if some nodes are down • may return stale data during partition
Partition Tolerance (CAP)	System continues despite network split	System operates correctly even when network messages are lost or delayed between nodes.
ACID Properties	Traditional relational transactions	• Atomicity: all-or-nothing • Consistency: valid state transitions • Isolation: concurrent execution safety • Durability: persisted writes survive failures.
BASE Properties	DynamoDB, Cassandra	• Basically Available: responds even if inconsistent • Soft state: may change without input • Eventually consistent: converges over time.
CP Systems	etcd, Consul, ZooKeeper	• Prioritize Consistency and Partition tolerance • become unavailable during network partition to preserve consistency.
AP Systems	Cassandra, DynamoDB, Riak	• Prioritize Availability and Partition tolerance • remain available during partition but may return stale data.
Two Generals' Problem	Can't guarantee mutual commit over lossy channel	• Proves impossibility of reaching guaranteed consensus over an unreliable communication channel • motivates Saga, Outbox, and idempotency patterns

Table 2: Consistency Models

Model	Example	Description
Linearizability	`read(x) → 5` immediately after `write(x, 5)`	• Strongest consistency — operations appear atomic at a single point in time • real-time ordering preserved across all nodes.

Table 3: Consensus Algorithms

Algorithm	Example	Description
Raft	etcd, Consul, TiKV	• Understandable alternative to Paxos: strong leader, log replication, term-based elections • explicitly designed for implementability

Table 4: Time and Ordering in Distributed Systems

Concept	Example	Description
Lamport Timestamps	Counter increments: $C_i = C_i + 1$	• Logical clock assigning scalar values to events • captures happened-before relation • if $a \to b$ then $C(a) < C(b)$.