Database Sharding diagram template
Partition data across several databases with a routing layer, a shard map and a rebalancing job.
About this design
Sharding splits one logical dataset across several databases so that both storage and write throughput can scale horizontally. The central decision is the shard key: a good key spreads load evenly and keeps the data a request needs on one shard, while a poor key creates hot spots or forces expensive queries across every shard. A routing layer looks up the key in a shard map, either by hash or by range, and sends the query to the right database. The diagram includes a small directory database for that map and a rebalancing job that moves ranges when a shard grows too large. Use it to talk through cross-shard joins and transactions, which you should design away, resharding without downtime, per-tenant sharding in B2B products, and why you should exhaust replicas, caching and indexing before you accept this complexity.
Diagram as text
This is the source of the diagram, in the ArchBoard diagram DSL. Paste it into Tools, Diagram from text to rebuild or change it.
title "Database sharding"
direction LR
service app "Application" -> service router "Shard router"
router -> db postgres "Shard map"
router -> db postgres "Shard 1"
router -> db postgres "Shard 2"
router -> db postgres "Shard 3"
cron "Rebalancer" -> shard-map
rebalancer -> shard-1
