Database sharding
Sharding partitions a logical dataset across multiple physical nodes, enabling horizontal scale-out when a single instance hits throughput or storage ceilings. Meridian's recipe engine uses range-based sharding keyed on recipe ID to keep related data colocated.
Shard key selection
We hash the recipe UUID with xxHash64 and map the result onto a consistent hash ring of 256 virtual nodes. This distributes load evenly and minimizes resharding churn when nodes join or leave.
Query routing
A stateless router layer inspects the shard key from the request context and fans out only when a query spans multiple shards. Single-shard reads hit one node directly, keeping p99 latency under 4 ms.
Rebalancing
When capacity is added, the control plane drains a subset of virtual nodes, replays the write-ahead log on the new shard, and atomically flips the routing table. No downtime, no stale reads.
Meridian currently runs 12 shards across 3 regions. Each shard holds ~4M recipes and sustains 22k QPS at peak.