Pattern · seen in 2 breakdowns across 2 companies
Shard-Key Colocation
Definition
When sharding, place every row that must be read or committed together on the same shard, by two coordinated choices: shard the full set of tables that reference each other (not just the big one), and partition them all by the same key — the entity whose boundary matches the application's transaction and query patterns. Transactionality guarantees stop at a single host; colocation is how a sharded system keeps the transactions it actually needs without distributed coordination.
The failure case the pattern prevents is quiet corruption at the seams: a parent row on one shard, its children on another, and a delete that succeeds on one side while the update on the other fails. The design work is choosing the colocation entity — the workspace, the guild, the user — such that real queries stay inside it and load spreads acceptably across instances of it.
When it applies
Tradeoffs
The same move, 2 ways
Every row is a production system that bet on this pattern — the note says how, in that system's own terms.
Often used together
Patterns sharing breakdowns with this one — derived from co-occurrence, threshold ≥2 shared.
Problems this pattern answers
The walls where its breakdowns live — each opens the cross-company comparison.