The ideas behind
every system you'll design.

The CAP theorem states that during a network partition — when some nodes can't reach others — a distributed store must choose between Consistency (every read returns the latest write) and Availability (every request still gets a non-error response). Partition tolerance isn't optional in a real network, so the real choice is CP or AP.

But CAP is binary and only speaks about partitions. PACELC extends it: else, when the system is running normally, you still trade Latency against Consistency. And "consistency" itself is a spectrum — from linearizable (behaves like a single copy) down through causal to eventual (replicas converge, given time).

When operations overlap, you risk race conditions: lost updates, dirty reads, and double-spends. Locking serializes access so only safe interleavings happen. The strategy you pick depends on how often operations actually collide.

Pessimistic locking assumes conflict is likely and takes the lock before touching data — others wait. Optimistic locking assumes conflict is rare: read a version number, do the work, and only at commit check whether the version changed, retrying if so. Modern databases also use MVCC to give readers a consistent snapshot without blocking writers.

Partitioning (sharding) splits one dataset across many machines so each holds a slice — this scales capacity and throughput. The hard part is the key: hash the key for even spread, or range-partition it for efficient scans. Naïve hashing breaks when you add a node, so production systems use consistent hashing, which moves only a small fraction of keys when the cluster changes.

Replication copies the same data onto several machines — this gives fault tolerance and read scaling. A common pattern is one leader taking writes and streaming them to followers. Quorum systems generalize this: with N replicas, require W writes and R reads such that W + R > N to guarantee overlap. Real systems do both — shard for scale, replicate each shard for durability.

Many problems reduce to consensus: who is the leader, what's the next entry in the replicated log, did this transaction commit? Raft and Paxos let a majority quorum agree safely even when a minority of nodes fail. Raft makes this approachable with an explicit leader election plus log replication — it's what powers etcd, Consul, and CockroachDB.

Above the cluster, distributed transactions coordinate work across services. Two-phase commit (2PC) gives atomicity but blocks if the coordinator dies; the saga pattern trades atomicity for availability using compensating actions. And because networks retry, every operation that mutates state should be idempotent — applying it twice has the same effect as once.