Almost every modern data platform, from Kafka and Cassandra to Snowflake and Spanner, is a distributed system. This section explains the core ideas they all share: how data is split, copied, agreed upon and read consistently when machines and networks fail.
A distributed data system stores and processes data on several machines that communicate over a network. We distribute for three reasons: the data or load is too big for one machine (scale), one machine failing must not stop the service (fault tolerance), and users are spread across the world (latency). The price is that networks delay, reorder and drop messages, clocks disagree, and machines fail partially, so problems that are trivial on one computer, such as "what is the latest value?", become hard.
Four ideas fit together. Partitioning (sharding) splits the data so each node owns a subset. Replication keeps copies of each partition on several nodes. Consensus lets nodes agree on a single value or order, such as which replica is leader, even when some fail. Consistency models state precisely what a read may return given concurrent writes and replication lag, and the CAP and PACELC results describe the unavoidable trade-offs between consistency, availability and latency.
A good reading order is: partitioning and replication first, since they are the mechanisms you configure every day; then consistency models, which give the vocabulary for what those mechanisms guarantee; then CAP and PACELC, which explain why no system gets everything; and finally consensus, the algorithmic core that makes strong guarantees possible. Each page includes diagrams and runnable code.
| Question you are asking | Concept | Typical knobs |
|---|---|---|
| My table no longer fits on one node or one node is too slow | Partitioning and sharding | Partition key, hash vs range, number of partitions |
| A node failure must not lose data or stop reads | Replication | Replication factor, sync vs async, W and R quorums |
| Which node is the leader? Did this write commit? | Consensus (Raft, Paxos) | Cluster size (odd numbers), election timeouts |
| Can a user see stale or out-of-order data? | Consistency models | Linearizable, causal, eventual; read-your-writes |
| What happens during a network partition, and what does consistency cost in latency? | CAP and PACELC | Consistency level per query, region placement |
In practice these are configured together. A Kafka topic, for instance, chooses a number of partitions (partitioning), a replication factor and min.insync.replicas (replication), relies on a controller quorum (consensus), and its producer acks setting determines the durability guarantee a write receives.