Scaling
When do you shard?
Later than the conference talks say, earlier than the outage. The conditions that genuinely require sharding, and the key choice that decides the next decade.
By TIS Partners · · 2 min
Sharding is the decision most mythologized by systems that needed it and most regretted by systems that did not. Both literatures are true. The discipline is knowing which story you are in, and the tell is arithmetic, not ambition.
What must be true before sharding is the answer?
Write saturation on a tuned single primary, after the cheaper ladder is exhausted: queries tuned, pool sized to reality, hardware maxed (2026 hardware forgives an enormous amount; a single node now carries what justified sharding projects a decade ago), reads offloaded to replicas, hot tables partitioned locally, archival data actually archived. Most shops that reach the top of that ladder discover their write problem was one table, one counter, or one queue wearing a database costume, each with a cheaper local remedy.
The second legitimate trigger is not scale but jurisdiction: data residency requirements that assign rows to geographies. That is sharding chosen by lawyers, and it is often better engineering than the performance-driven kind, because the shard key is handed to you.
Which decision decides the next decade?
The key. Everything else about sharding is machinery; the key is destiny. A good key distributes load evenly, appears in nearly every query, and never changes for the life of the row. Tenant ID serves multi-tenant B2B beautifully, until the one whale customer outgrows their shard, so ask now: is the largest tenant growing faster than the median? Time-based keys write all load to the newest shard by construction. And any query missing the key becomes a scatter-gather across every shard, which means your p99 becomes the tail of the slowest shard, every time.
The unglamorous parts arrive after the key: resharding (the count you pick will be wrong eventually; consistent hashing or directory schemes make wrongness survivable), cross-shard transactions (now a distributed systems problem you own), and the operational multiplication, where one backup process becomes N and the incident folder learns new vocabulary.
What would we sign off on?
A sharding proposal that shows the exhausted ladder with numbers; a key justified against the three tests above with production query distributions, not intuitions; a resharding story rehearsed on paper; and a statement of what the org gives up (ad hoc cross-tenant queries, single-transaction semantics) signed by the people who will miss them. That document is a morning's work for a team that is genuinely ready and an impossible ask for one that is not, which is precisely the review's function.
Shard when the arithmetic forces it or the law requires it. Until then, the boring ladder, rung by rung. The systems that sharded well all report the same thing: they knew the date the single node would fail, months ahead, from a graph. The date made the decision. It usually does.