Sharding & Hot Keys
Splitting data across machines and cooling down celebrity keys.
Sharding splits one dataset across multiple database machines because no single machine can hold it or absorb its writes. The shard key — the field that decides which machine each record lives on — is the whole game: queries that stay on one shard stay fast, and queries that must visit every shard (scatter-gather) get slow.
The animation starts with a single overflowing database splitting into four shards. Records fly to their shard by hash color — hash the key, land on a machine. Then the failure mode: one shard glows red-hot as a celebrity user's traffic all converges on the same key. That is a hot shard, and adding more shards does not help, because the hash keeps sending that one key to the same place. Watch the fix: a salt shaker animation appends a small random suffix to the celebrity's key, splitting their traffic across several shards to cool it down.
Two interview cautions. First, do not shard early — a single Postgres comfortably handles a few TB and around 10k writes/sec, so proposing shards at 500GB reads as over-engineering. Second, when you do shard, be ready to name your shard key, defend it against your dominant query, and admit one problem it creates.