Capítulo 7 – Arquitetura distribuída

Toda aplicação começa simples: um banco de dados, uma API e um front-end consumindo essa API. Funciona bem no início. Mas conforme o produto cresce, usuários aumentam e os requisitos ficam mais complexos, surge um problema inevitável: um único serviço não aguenta o peso de tudo.

É aqui que entra a arquitetura distribuída — um conjunto de padrões e práticas para dividir responsabilidades entre múltiplos serviços conectados por eventos, filas e protocolos de comunicação.

⚙️ O que é uma arquitetura distribuída?

De forma simples, é quando você quebra um sistema em partes independentes, cada uma responsável por uma função, e as faz conversar de forma confiável.

Exemplos de abordagens:

Microservices: vários serviços pequenos, especializados, comunicando-se via APIs ou mensageria.
Event-driven: sistemas que reagem a eventos, propagando mudanças de estado por mensagens assíncronas.
CQRS + Event Sourcing: separar leitura e escrita, mantendo histórico completo do sistema.

💡 Por que distribuir?

1. Escalabilidade Escale apenas a parte que precisa, sem duplicar o sistema inteiro.

Exemplo: um e-commerce recebe 90% do tráfego no “checkout” — só essa parte precisa escalar.

2. Resiliência Uma falha em um serviço não deve derrubar o ecossistema.

Exemplo: se o módulo de recomendações cair, o cliente ainda consegue comprar.

3. Flexibilidade Times diferentes podem evoluir serviços distintos sem bloqueios ou dependências desnecessárias.

🛒 Exemplo prático: um marketplace

Pense em um marketplace como Mercado Livre ou Amazon. Você pode quebrar o sistema em:

Catálogo (listagem de produtos)
Carrinho (gerenciamento de itens)
Checkout (pagamentos)
Notificações (e-mails e push)
Entrega (logística)

Em um monólito, qualquer mudança em “entrega” exigiria deploy de todo o sistema. Com uma arquitetura distribuída, cada módulo evolui de forma independente, respeitando contratos e padrões de comunicação.

🧩 Padrões essenciais

⚠️ Falhas comuns

Distribuir cedo demais: Startups que criam dezenas de microservices antes de validar o produto gastam mais com infraestrutura do que com valor entregue.

Falsa independência: Serviços que “parecem” independentes, mas compartilham o mesmo banco de dados, criando gargalos ocultos.

Falta de governança: Sem padrões de autenticação, contratos e monitoramento, a arquitetura se torna um caos de integrações frágeis.

🐜 Metáfora: o formigueiro

Um monólito é como uma única formiga carregando todo o peso. Uma arquitetura distribuída é um formigueiro: cada formiga tem sua função, mas todas cooperam para manter a colônia viva.

O papel do Staff Engineer é garantir que esse formigueiro funcione em harmonia, com coordenação, propósito e resiliência.

🧠 Exercício prático

Escolha um sistema que você conhece e reflita:

Quais módulos poderiam ser extraídos como serviços independentes?
Quais comunicações devem ser síncronas (APIs) e quais assíncronas (eventos/mensagens)?
Se um serviço cair, o sistema continua funcional?
Existem pontos únicos de falha?

💬 Staff Insight

“Arquitetura distribuída não é sobre microservices bonitos. É sobre construir sistemas que continuam de pé mesmo quando partes falham.”

🧭 Checklist prático

Meus serviços são realmente independentes ou apenas parecem?
Já defini padrões claros de comunicação (REST, gRPC, eventos)?
Tenho observabilidade ponta a ponta?
Consigo escalar partes específicas sem replicar tudo?
Sei qual é o ponto mais frágil da minha arquitetura hoje?

👉 Neste capítulo, você aprendeu a pensar em sistemas distribuídos, resilientes e escaláveis. No próximo, entraremos em um tema essencial para Staff Engineers: FinOps e eficiência técnica — porque não basta desenhar bonito, é preciso entender o custo de cada decisão.