System Design/02 - Componentes/Databases2 min
Federation
- Que problema isso resolve?
- Quando usar / quando NÃO usar?
- Qual o principal trade-off?
- Como isso falha em produção?
Conceito
Também chamado particionamento funcional ou vertical: dividir o banco por domínio, não por linhas.
banco único
↓
banco-usuarios · banco-produtos · banco-pedidos
Cada domínio ganha seu próprio banco, com o próprio hardware, ajuste e ciclo de manutenção.
| Federation | Sharding | |
|---|---|---|
| Divide por | Domínio (tabelas) | Linhas (mesma tabela) |
| Cada nó tem | Tabelas diferentes | Mesmas tabelas, dados diferentes |
| Complexidade | Menor | Maior |
| Limite | O maior domínio individual | Praticamente ilimitado |
Trade-offs
Federation é o passo natural antes do sharding e frequentemente resolve o problema sozinho: separar as escritas de três domínios em três bancos triplica a capacidade de escrita com uma fração da complexidade de particionar.
Também traz ganhos secundários reais: cada banco pode ser ajustado para seu perfil (o de produtos é leitura pesada, o de pedidos é escrita pesada), pode escalar independentemente, e uma manutenção afeta só um domínio.
O que se perde é o mesmo que se perde em Microservices — e não por acaso: junções e transações entre domínios acabam. JOIN usuarios ON pedidos deixa de existir; a composição passa para a aplicação, e a consistência entre domínios vira eventual.
O limite estrutural: federation só escala até o maior domínio isolado. Se o banco de pedidos sozinho já não aguenta, dividir por domínio não ajuda mais — aí é sharding.
E há uma armadilha comum: separar os bancos e manter junções via consultas cruzadas ou views. Isso recria o acoplamento e adiciona latência de rede, entregando o pior dos dois mundos.
Exemplo prático
Um monolito cujo banco satura. A análise mostra que a escrita se distribui como: 60% em eventos_analytics, 30% em pedidos, 10% no resto.
Mover apenas eventos_analytics para um banco separado — provavelmente para um banco especializado em série temporal — reduz a carga do banco principal em 60% com uma migração relativamente contida.
Nenhuma linha precisou ser particionada, nenhuma shard key precisou ser escolhida, e as junções dentro de pedidos continuam funcionando. Esse é o argumento de federation: ela ataca a maior fatia do problema com a menor mudança estrutural.
Relacionado
Parte de Databases · roadmap.sh/system-design