Federation
Split the data by feature into separate databases, so each service owns its tables and one busy feature cannot slow the rest.
Federation gives each feature its own database, so orders, users and the catalog stop sharing one machine.
Use it when#
One database serves unrelated features, and a slow report or a busy feed slows checkouts.
Teams want to deploy and size their own data without asking each other.
The features rarely join each other's tables.
How it works#
Pick the seams where tables do not join: orders on one database, the catalog on another, sessions on a third. Each service talks to its own database, and anything it needs from another feature comes through that service's API, not a join. If orders get 1,000 writes a second and the catalog 20, they stop competing for the same disk.
Unlike sharding, every database holds different tables, so federation spreads load by feature, not by row. The two combine: shard the biggest federated database later.
What it costs#
A query or transaction that crossed features now crosses services. Joins become application code, and a change that touches two databases needs a saga or an accepted gap. You also run more databases, with more backups and more things to patch. Federation helps only up to the number of features, and the busiest one is still one database.
In Quorum#
Drag to pan. Hold Ctrl or Cmd and scroll to zoom.
| Where | Setting | Value | Why |
|---|---|---|---|
| App Server | Instance size | small | Small. The orders service carries checkouts and writes. |
| App Server | Instance size | small | Small. The catalog service carries page views and reads. |
| Database | Instance size | small | Holds orders only, so writes never queue behind catalog reads. |
| Database | Instance size | small | Holds the catalog only, and can be resized apart from orders. |
| Link Load Balancer → App Server | Request kinds | write,buy,login | The Load Balancer sends writes, checkouts, and logins to the orders service. |
| Link Load Balancer → App Server | Request kinds | page,read,search,upload,media,rt,bot,job,report,ai | Everything else goes to the catalog service. |
Research this Design needs: Load balancing, Load balancing.
The game has no per-table split, so the Design splits by request kind. The Load Balancer Links carry a list of request kinds, so writes, checkouts and logins reach the orders service and everything else reaches the catalog service. Each App Server has its own Database, sized apart from the other.
Split the database by feature is the ladder rung, and The data tier covers the choices.