Split the data to scale.
Copy it to survive.

Partitioning (sharding) splits one dataset across many machines so each holds a slice — it scales capacity and throughput. Replication copies the same data onto several machines — it provides fault tolerance and read scaling. They're orthogonal, and production systems combine them: shard the data into N partitions, then keep R replicas of each partition.

The partitioning strategy decides which node owns a given key.

Plain hashing — node = hash(key) % N — has a fatal flaw: change N (add or lose a machine) and almost every key remaps, forcing a full reshuffle. That's what consistent hashing fixes.

Map both keys and nodes onto a circular hash space (a ring). A key is owned by the first node found clockwise from its position. When a node joins, it takes over only the keys between it and its predecessor; everyone else is untouched. When a node leaves, only its keys move to the next node.

One refinement matters in practice: virtual nodes. Each physical machine is placed at many points on the ring, so load is even and removing a node spreads its keys across all survivors rather than dumping them on one neighbour.

The savings are dramatic and measurable. The naive scheme hash(key) mod N remaps almost every key the instant N changes; consistent hashing moves only the new node's share:

That gap is the difference between a resharding storm and a quiet rebalance. The runnable version below counts the moved keys both ways.

Even spread depends entirely on the shard key. A bad key creates a hot partition — one shard drowning in traffic while others idle. A celebrity user on a "shard by user_id" scheme is the canonical example.

When a single key is unavoidably hot, the fixes are: add a random suffix to fan it across sub-partitions, cache it separately, or give it dedicated capacity. The shard key is the one decision that most often makes or breaks the design.

Asynchronous replication introduces replication lag: a follower can be behind the leader, so a read from it may be stale. That silently breaks read-your-writes — a user edits their profile, then sees the old value. The fix is to route a user's reads to the leader (or a caught-up follower) for a short window after they write.

Leaderless systems make the consistency knob explicit. With N replicas, require W acknowledgements per write and R replicas per read. If W + R > N, the read and write sets overlap on at least one current replica — strong consistency. Drop below that and you trade freshness for latency and availability.