← BACK TO DRAWING SET
SPECIFICATION · CONCEPT BRIEFDWG · 07-SHARD-THE-DATABASE

Shard the Database

When one database can't keep up, slice the data across many.

§01Vertical limits

A single database has a maximum throughput — eventually you'll saturate it no matter how big the machine. Read replicas help with reads, but writes still need to land on the primary.

§02What sharding is

Sharding partitions your data across multiple databases by a shard key — typically a hash of the user id, account id, or whatever the request is keyed on. Shard 0 holds keys hashing to 0, shard 1 holds keys hashing to 1, and so on.

A shard router (also called a coordinator) sits in front. Given a request's key, it computes the hash and forwards to the correct shard. Aggregate throughput scales nearly linearly with shard count.

§03Trade-offs

  • Cross-shard queries are expensive (must fan out to every shard and merge results).
  • Resharding (changing the number of shards) is operationally painful — pick a key with good distribution up front.
  • Hot keys (one user generating disproportionate traffic) can still saturate a single shard.
⚑ NOTE
Consistent hashing
Hashing by `key % N` breaks horribly when N changes. Production systems use consistent hashing rings so adding a shard only moves a small fraction of keys.
⚑ CHEATSHEET · QUICK REFERENCE
  • Pick a shard key with high cardinality and even distribution.
  • Aggregate capacity ≈ N × per-shard capacity.
  • If one shard is hot, the average looks fine but users on that shard suffer.
▸ THE EXERCISE

One database can't keep up. Add a load balancer in front of multiple servers, then a shard router that deterministically partitions writes across multiple databases by key. More shards = more aggregate throughput.

▸ START EXERCISEBACK TO DRAWING SET