Sharding

A single database server has limits: a fixed amount of disk, memory, CPU, and write throughput. You can buy a bigger machine for a while, which is vertical scaling, but eventually the largest available server is not enough, or it gets absurdly expensive. At that point you have to spread the data across many machines, which is horizontal scaling.

Sharding is horizontal scaling for a database. Instead of one server holding all hundred million users, you run several servers and each holds a portion, say twenty-five million each. Reads and writes for a given user go only to the shard that holds that user, so the total capacity is the sum of all the shards. This is the main way large systems scale writes, because unlike read replicas, sharding splits the write load too.

Every sharded system needs a shard key: the column whose value decides which shard a row belongs to. A router computes the shard from the key, for example by hashing the user_id and taking it modulo the number of shards, or by assigning ranges of the key to shards. From then on, any operation that knows the key goes straight to the right shard.

Choosing the shard key well is the hardest and most important decision in sharding. A good key spreads both data and traffic evenly across shards. A bad key creates a hotspot: if you shard an e-commerce system by country and most of your customers are in one country, that one shard gets hammered while the rest sit idle. The infamous version is the celebrity problem, where sharding social data by user means one hugely popular account overwhelms its shard.

Range sharding assigns contiguous ranges of the key to shards: A to H on shard one, I to P on shard two, and so on. It makes range scans easy, since nearby keys live together, but it is prone to hotspots, because real data is rarely spread evenly across ranges and new sequential keys all land on the last shard.

Hash sharding runs the key through a hash function first and shards on the result. This scatters even sequential or skewed keys evenly across shards, which is great for balancing load, but it destroys locality, so a query for a range of keys now has to hit every shard. Many systems use consistent hashing here so that adding or removing a shard moves only a small fraction of the data rather than reshuffling everything.

Sharding buys scale but charges a real tax. A query that does not include the shard key cannot be routed to one shard, so it becomes a scatter-gather that hits every shard and merges the results, which is slow and scales badly. Joins across shards are painful or impossible and often have to be done in the application. Transactions that span shards need distributed-transaction machinery that most teams try hard to avoid.

Resharding, changing the number of shards as you grow, is operationally heavy because it means moving large volumes of live data while the system keeps serving. Because of all this, the usual advice is to delay sharding as long as a single well-tuned database with read replicas can carry the load, and when you do shard, pick a key that keeps the queries you care about on a single shard.