Federation & Denormalization
Split by function first
Federation — functional partitioning — splits one database into several, by what the data is about rather than by which rows it holds. Users in one database, products in another, orders in a third.
It is worth reaching for before sharding because it is dramatically less invasive. Each database is smaller, so more of it fits in memory. Write traffic spreads across them, and each has its own replication and its own failure domain: an expensive analytics query on the products database no longer starves the checkout path.
It also tends to fall out of the org chart naturally, since teams already own functional areas. The boundaries usually already exist in your code; federation just makes them physical.
Joins and transactions across the boundary become distributed operations rather than cheap local ones. Some databases provide foreign access or distributed transactions, but they add latency, coordination, and new failure modes; many teams instead join in application code or keep a denormalised copy.
BEFORE AFTER (federated) ┌──────────────┐ ┌────────┐ ┌──────────┐ ┌────────┐ │ everything │ │ users │ │ products │ │ orders │ │ │ ───► └────────┘ └──────────┘ └────────┘ │ one machine │ each smaller, independently scaled │ one failure │ no cross-database joins └──────────────┘
Federation splits by table; sharding splits by row. Federation is bounded — you run out of functional areas — but it is much cheaper, so spend it first.
3 components2 connections0:00
Recording…