Database Federation¶
Split a database by function (orders, users, inventory) rather than by key range — each service gets its own database. Solves a different scaling problem than sharding, and creates a different set of cross-database query and consistency headaches.
flowchart LR
Junior["Junior: federation vs. sharding - splitting by function, not key"] --> Middle["Middle: cross-database joins and the query fan-out cost"]
Middle --> Senior["Senior: distributed transactions across federated databases"]
Senior --> Professional["Professional: federation at scale - query federation engines and data mesh"]
flowchart LR
App[Application] --> OrdersDB[(Orders DB)]
App --> UsersDB[(Users DB)]
App --> InventoryDB[(Inventory DB)]
Choose a level¶
| Level | Guide | You are done when |
|---|---|---|
| Junior | Federation vs. sharding | You can explain why splitting by function solves a different problem than splitting by key range. |
| Middle | Cross-database joins | You can explain why a "join" across federated databases becomes application-level work. |
| Senior | Distributed transactions | You can explain why a transaction spanning two federated databases can't use a normal BEGIN/COMMIT. |
| Professional | Federation at scale | You can evaluate a query federation engine or data mesh architecture for a real multi-database system. |
Practice rule¶
Before federating a database by function, ask: "which queries currently join across the tables I'm about to split apart?" Every one of those queries becomes cross-database application logic the moment you federate — know the cost before you pay it.