A arquitetura de microservices ganhou popularidade por permitir escalabilidade seletiva, deploy independente e maior resiliência. Mas construir sistemas distribuídos também introduz novos problemas: falhas em cascata, complexidade de comunicação, consistência eventual e custos operacionais.
Para enfrentar esses desafios, engenheiros recorrem a padrões de projeto que encapsulam soluções comprovadas. Neste artigo, vamos explorar 12 padrões essenciais, explicando quando aplicar, desafios, exemplos reais e como eles se combinam entre si.
1. API Gateway Pattern
O API Gateway atua como ponto único de entrada para todos os clientes (web, mobile, dispositivos IoT) e roteia as requisições para os microservices corretos.
Benefícios:
- Centraliza autenticação, autorização e rate limiting.
- Agrega respostas de múltiplos serviços em uma única chamada.
- Reduz acoplamento entre cliente e topologia interna.
Desafios:
- Ponto único de falha se não for redundante.
- Pode virar gargalo se sobrecarregado.
Exemplo real: O Netflix usa um gateway que adapta respostas conforme o tipo de dispositivo, aplicando compressão e filtragem específicas.
Combinação útil: API Gateway + API Composition Pattern para agregar dados de vários serviços em uma só resposta.
2. Saga Pattern
Transações distribuídas não funcionam como no mundo monolítico. O Saga Pattern resolve isso dividindo o processo em passos independentes com ações compensatórias em caso de falha.
Benefícios:
- Mantém consistência em ambientes distribuídos sem depender de 2PC.
- Isola falhas em um ponto específico do fluxo.
Desafios:
- Lidar com falhas intermediárias pode ser complexo.
- Fluxos assíncronos exigem orquestração clara.
Exemplo real: Em marketplaces, a reserva de estoque, cobrança e emissão de nota fiscal são passos independentes que precisam ser revertidos individualmente se algo der errado.
Combinação útil: Saga Pattern + Retry Pattern para dar resiliência em passos temporariamente indisponíveis.
3. Event Sourcing Pattern
Aqui, o estado de um sistema é reconstruído a partir de eventos armazenados, em vez de apenas manter o estado final.
Benefícios:
- Auditoria completa de todas as mudanças.
- Possibilidade de “voltar no tempo” e reproduzir estados.
Desafios:
- Consultas complexas exigem snapshots periódicos.
- Volume de dados pode crescer rapidamente.
Exemplo real: Sistemas bancários registram cada transação como evento, permitindo reconstruir o saldo a qualquer momento.
Combinação útil: Event Sourcing + CQRS para separar a complexidade de gravação e leitura.
4. CQRS (Command Query Responsibility Segregation)
Separa as operações de leitura e escrita, permitindo que cada lado seja otimizado de forma independente.
Benefícios:
- Escalabilidade seletiva para leitura ou escrita.
- Modelos de dados distintos para cada tipo de operação.
Desafios:
- Consistência eventual no lado de leitura.
- Mais componentes para monitorar.
Exemplo real: Aplicações que usam PostgreSQL para gravações e ElasticSearch para buscas rápidas.
Combinação útil: CQRS + API Gateway para criar rotas otimizadas para consultas.
5. Strangler Fig Pattern
Migrar um monólito inteiro de uma vez é arriscado. Esse padrão substitui partes dele gradualmente, como uma figueira que envolve e substitui a árvore original.
Benefícios:
- Migração sem grandes janelas de downtime.
- Redução de risco e controle do escopo.
Desafios:
- Sistemas híbridos exigem integrações temporárias complexas.
Exemplo real: Amazon iniciou a transição de seu monólito substituindo módulos específicos por microservices.
Combinação útil: Strangler Fig + API Gateway para encaminhar requisições ao novo ou antigo sistema conforme a evolução.
6. Service Discovery Pattern
Permite que microservices encontrem uns aos outros dinamicamente, sem endereços fixos.
Benefícios:
- Facilita escalabilidade automática.
- Remove necessidade de configuração manual de endpoints.
Desafios:
- Segurança e autenticação durante a descoberta.
- Sincronização em ambientes multi-região.
Exemplo real: Kubernetes usa Service Registry interno para resolver nomes de serviços em IPs.
Combinação útil: Service Discovery + Circuit Breaker para evitar chamadas repetidas a serviços indisponíveis.
7. Circuit Breaker Pattern
Evita sobrecarregar um serviço com falhas contínuas, bloqueando chamadas após um limite e tentando novamente após um intervalo.
Benefícios:
- Previne efeito cascata.
- Dá tempo para serviços se recuperarem.
Desafios:
- Definir limiares corretos para abrir e fechar o circuito.
- Risco de “flapping” (abre e fecha constante).
Exemplo real: Resilience4j implementa circuit breakers com métricas configuráveis.
Combinação útil: Circuit Breaker + Retry Pattern para controlar quando e como tentar novamente.
8. Bulkhead Pattern
Isola recursos para diferentes operações ou serviços, garantindo que uma falha não derrube todo o sistema.
Benefícios:
- Maior resiliência.
- Protege serviços críticos.
Desafios:
- Configuração incorreta pode desperdiçar recursos.
Exemplo real: Separar pools de threads para processamento de pagamentos e consultas de catálogo.
Combinação útil: Bulkhead + Saga Pattern para garantir isolamento em fluxos críticos.
9. Database per Service Pattern
Cada microservice possui seu próprio banco de dados, evitando dependências fortes.
Benefícios:
- Autonomia total entre equipes.
- Possibilidade de usar o banco mais adequado para cada caso.
Desafios:
- Complexidade para consultas que cruzam dados de múltiplos serviços.
- Necessidade de mecanismos de sincronização ou eventos.
Exemplo real: Serviço de catálogo usando MongoDB e serviço de pedidos usando PostgreSQL.
Combinação útil: Database per Service + Event Sourcing para manter consistência entre domínios.
10. Sidecar Pattern
Serviço auxiliar executado junto ao microservice principal para oferecer funcionalidades de suporte.
Benefícios:
- Facilita observabilidade e segurança.
- Padroniza comportamentos sem alterar o código do serviço.
Desafios:
- Mais containers para gerenciar.
- Consumo adicional de recursos.
Exemplo real: Istio usa sidecars Envoy para controle de tráfego e métricas.
Combinação útil: Sidecar + Service Discovery para monitorar e registrar serviços automaticamente.
11. Retry Pattern
Reexecuta chamadas que falham, com controle de tentativas e intervalo crescente.
Benefícios:
- Tolerância a falhas temporárias.
- Melhora a disponibilidade percebida.
Desafios:
- Sem jitter, pode causar thundering herd.
- Pode mascarar problemas graves se mal configurado.
Exemplo real: AWS SDK implementa retry com backoff exponencial e jitter.
Combinação útil: Retry Pattern + Circuit Breaker para evitar sobrecarga.
12. API Composition Pattern
Combina dados de múltiplos microservices em uma única resposta, geralmente no backend.
Benefícios:
- Reduz número de chamadas entre cliente e servidor.
- Melhora a experiência do usuário.
Desafios:
- Latência acumulada se um dos serviços for lento.
- Pode ser ponto único de falha.
Exemplo real: Backend for Frontend (BFF) agregando dados de pedidos, perfis e recomendações.
Combinação útil: API Composition + CQRS para otimizar consultas compostas.
Como combinar padrões para máxima resiliência
Na prática, poucos sistemas usam apenas um padrão. Combinações comuns incluem:
- API Gateway + Strangler Fig + Service Discovery para migração de legado.
- Circuit Breaker + Retry + Bulkhead para alta disponibilidade.
- CQRS + Event Sourcing + Database per Service para sistemas financeiros.
