Skip to content
Optimal Lab

System design · interactive

Sharding: choosing the shard key

One orders table is too big for one database, so it's split across 4 shards. The shard key decides where every row lives, which shard takes the new writes, and how many shards each query has to ask.

App

WHERE customer_id = 19

Shard router

hash(customer_id)

Shard 1

9 rows · +4/day

Shard 2

13 rows · +4/day

Shard 3

9 rows · +4/day

Shard 4

17 rows · +8/day

rows storednew writes today
Shard 1
9
4
Shard 2
13
4
Shard 3
9
4
Shard 4
17
8

Shard key hash(customer_id): rows 9 / 13 / 9 / 17, new writes 4 / 4 / 4 / 8. Load is spread.

Shard key

shard = hash(customer_id) % 4

Query

  1. 1

    A column every row has, used to decide its shard. It is very hard to change later: every row would have to move.

    shard = hash(customer_id) % 4

  2. 2

  3. 3

  4. 4

  5. 5

In production

Tools and technologies

When one database is too big, these systems split it by a shard key and route queries for you.

Not tied to one language — use these names when you search docs or design a system.