Shard the database
Split the Database into shards by a key, so writes divide across several primaries once one box at its largest size is full.
Split one Database into several shards on a key, so each shard takes a share of the writes.
Move up when#
The primary is at its largest size and still saturates on writes, with replicas already added.
Disk operations queue on the primary even after you buy faster volumes.
Vertical growth has run out, so the next step cannot be a bigger box.
The Design#
Drag to pan. Hold Ctrl or Cmd and scroll to zoom.
| Where | Setting | Value | Why |
|---|---|---|---|
| App Server | Instance size | medium | Medium, so the Database is the tier that shows its limit. |
| Database | Shards | 4 | Writes split four ways, so each shard takes a quarter of them. Reads and writes now scale with the count. |
| Database | Shard key | hash | A hash of the user ID spreads Users evenly, so no shard becomes the busy one. |
| Database | Instance size | medium | Each shard is another copy of this size, so size it for one shard. |
Research this Design needs: Read replicas, Sharding.
The App Server calls one Database Node. The Node now stands for several shards, each a copy of its size. A request goes to the shard that owns its key.
Why it works#
Reads and writes scale with the shard count, because each shard sees only its slice. The key decides how even that slice is. A hash of the user ID spreads Users evenly. A range key sends new Users to the last shard, and a tenant key sends a large tenant to one shard, so those leave a hot shard. A region key keeps data near its Users but pays a round trip for far ones.
What it costs#
Every shard bills as a full Database. A report or search touches every shard, so each shard past the first adds CPU and a little latency. A transaction that spans shards commits on each, and any one can fail it. Changing the count or the key later is a resharding that costs Dev Hours and a long copy, so choose the key early. The game offers no consistent-hashing option for the shard map, only these four keys.
In Quorum#
Set Shards and Shard key on a Database. Research Sharding. The Big tenant hot shard incident shows a bad key. See sharding, hot keys and hot shards and Scale the database. The next rung, distributed SQL and leaderless stores, moves the splitting into the store itself.