Partitioning by Hash of Key
Hashing the key to spread skewed data evenly — what a partitioning hash actually needs to be, why "consistent hashing" is the wrong name for it, and the range queries you give up to get the even distribution.
Hashing the key to spread skewed data evenly — what a partitioning hash actually needs to be, why "consistent hashing" is the wrong name for it, and the range queries you give up to get the even distribution.
Why a single very hot key defeats every partitioning scheme in this series, the random-suffix trick that splits it, and the read fan-out and bookkeeping you take on in exchange.
Why replication alone runs out of road, what a partition actually is under six different names, and why choosing how to partition is independent of choosing how to replicate.
Assigning each partition a continuous span of the key space — why the boundaries have to follow the data, what it buys on range scans, and the hot spot a timestamp key walks straight into.
Why concurrent writes survive even a strict quorum, why last-write-wins is only safe for keys you never rewrite, and why two operations minutes apart can still be concurrent.
Why w + r > n is a probability dial rather than a guarantee — the edge cases that return stale data anyway, the consistency guarantees quorums never provide, and why staleness is so hard to monitor.
What a leaderless database does when a client cannot reach its quorum at all — why the fix buys durability rather than consistency, and how the same model stretches across datacenters.
Closing the Database Replication series — the four reasons to replicate, the three approaches side by side, and the one trade-off that turns out to be underneath all of them.
How a database tells an overwrite from a conflict — the version-number algorithm behind siblings, why merging by union resurrects deleted items, and what a version vector adds once there is no single replica.
How Dynamo-style databases let any node accept writes, tolerate node failures without failover, repair stale replicas through read repair and anti-entropy, and tune the quorum condition w + r > n.
Three scenarios where multi-leader replication makes sense — multi-datacenter deployments, offline-capable clients, and collaborative editing — and why write conflicts are the price you pay.
How multi-leader systems wire their nodes together — circular, star, and all-to-all topologies — and why all-to-all introduces a causality problem that version vectors solve.
Why write conflicts are unavoidable in multi-leader setups, the full spectrum of resolution strategies from last-write-wins to CRDTs, and what actually counts as a conflict.
Two more subtle problems caused by replication lag — monotonic reads and consistent prefix reads — and the approaches that address all three consistency guarantees together.
An introduction to why databases replicate data across multiple nodes, and the fundamental trade-offs that follow from that decision.
What happens when asynchronous replication lets followers fall behind — and the first concrete problem it causes: reading your own writes.
How single-leader replication works under the hood — the leader-follower model, the replication log, and the trade-off between synchronous and asynchronous replication.
How databases actually ship changes from leader to followers — the four approaches to replication logs, their trade-offs, and why the format you choose affects everything from rolling upgrades to change data capture.
The operational side of leader-based replication — how to add a new follower without downtime, and what actually happens when nodes fail.