Sharding is horizontal partitioning: you split your dataset across N machines so each holds ~1/N of the data. You do this when a single node can no longer handle the storage, write throughput, or working-set memory of your workload. Replication makes copies; sharding makes slices. Most real systems do both.

The whole game is picking a shard key. Every read and write is routed by hashing or ranging on this key, so if you pick wrong, you'll pay for years. Three common strategies:

• Hash-based sharding: shard = hash(key) % N. Even distribution, but range queries hit every shard, and adding a node reshuffles almost everything (fix this with consistent hashing).
• Range-based sharding: shard 1 holds keys A–F, shard 2 holds G–M, etc. Range scans are fast, but sequential keys (timestamps, auto-increment IDs) create write hotspots on the "last" shard.
• Directory-based sharding: a lookup service maps key → shard. Maximum flexibility, but the directory becomes a single point of failure and a coordination bottleneck.

Real example: Instagram sharded Postgres by user ID. Every user's photos, comments, and likes live on the same shard, so loading a profile is one shard hit. But cross-user queries ("photos liked by users I follow") become expensive scatter-gather operations. That's the trade — you optimize for the 95% access pattern and eat the cost of the 5%.

The hotspot problem: If you shard tweets by user_id and one user has 200M followers (hi, Taylor Swift), that shard melts under fan-out writes while others idle. Fix: sub-shard hot keys, or use a hybrid key like hash(user_id, tweet_id % 100).

Rule of thumb for shard count: pick more shards than you think you need — typically 10–100× your current node count. Rebalancing shards between nodes is cheap; splitting a shard in half under production load is nightmare fuel. Vitess, MongoDB, and Cassandra all lean into "many small shards" for this reason.

What breaks after you shard:

• Joins across shards are now application-level scatter-gather.
• Transactions spanning shards need 2PC or sagas (both painful).
• Unique constraints on non-shard-key columns require a coordination layer or global index.
• Resharding is a migration project, not a config change.

Don't shard until you have to. Vertical scaling, read replicas, and archival tables buy you years. Sharding is a one-way door — reverse it and you're rewriting your data layer.