Sharding
Splitting data across many machines so no single node holds — or bottlenecks on — all of it.
Sharding partitions a dataset by a shard key across nodes so reads and writes spread out and capacity scales horizontally. The hard parts are choosing a key that avoids hotspots and rebalancing as the cluster changes — where consistent hashing helps.
Worked example: shard users by a hash of user_id and load spreads evenly; shard by signup date and every new user hammers one shard (a hotspot) while old shards idle; shard by country and a few large countries skew everything. Gotcha: the shard key must appear in your common queries, or every read fans out to all shards (a scatter-gather that defeats the point). And even a good key can hotspot on a “celebrity” value — one viral account whose rows all live on one shard — which is why hot keys sometimes need their own special handling.