MONOPOLY — Mergulho Profundo em Padrões de Design

Quando Usar

• Use esta habilidade quando a tarefa corresponder a esta descrição: Documento de referência para padrões de monopólio.

Sumário

1. CQRS
2. Event Sourcing
3. Padrão Saga
4. Circuit Breaker
5. Bulkhead
6. Strangler Fig
7. Sidecar / Service Mesh
8. Padrão Outbox
9. Consistent Hashing
10. Backpressure
11. Leader Election
12. Two-Phase Commit

1. CQRS (Command Query Responsibility Segregation)

O que é: Separa o modelo de leitura (Query) do modelo de escrita (Command) em serviços, bancos de dados ou fluxos de código distintos.

Quando usar:

• Carga de leitura é 10×+ carga de escrita (a maioria dos aplicativos web)
• Consultas de leitura são agregações complexas sobre dados de escrita
• Necessidade de otimizar os caminhos de leitura e escrita independentemente
• Modelo de domínio é complexo (contextos DDD)

Implementação:

Write Path:  Client → Command API → Write DB (normalized, PostgreSQL)
Read Path:   Client → Query API  → Read DB (denormalized, Redis / Elasticsearch)
Sync:        Write DB → CDC (Debezium) → Message Queue → Read DB updater

Trade-offs:

• ✅ Escalabilidade independente de leitura e escrita
• ✅ Esquemas otimizados para cada tipo de operação
• ❌ Consistência eventual entre os modelos de escrita e leitura
• ❌ Complexidade aumentada; dois modelos para manter

Usuários no mundo real: Amazon (serviço de pedidos), LinkedIn (feed)

2. Event Sourcing

O que é: Armazena o estado como uma sequência de eventos imutáveis em vez do estado atual. Reconstrói o estado atual reproduzindo os eventos.

Quando usar:

• Rastro de auditoria completo é um requisito regulatório (fintech, saúde)
• Necessidade de reproduzir o histórico para depuração ou análise
• Domínio complexo com muitas transições de estado
• Necessidade de derivar múltiplas projeções de leitura dos mesmos dados

Implementação:

Event Store: append-only log (Kafka, EventStoreDB)
Snapshots:   periodic snapshots to speed up state rebuild
Projections: consumers build read models from events

Trade-offs:

• ✅ Histórico de auditoria completo; perfeito para conformidade
• ✅ Depuração por reprodução e viagem no tempo
• ❌ Consultar o estado atual requer manutenção de projeção
• ❌ Evolução do esquema de eventos é difícil
• ❌ Alto overhead de armazenamento ao longo do tempo

3. Padrão Saga

O que é: Gerencia transações distribuídas entre microsserviços por meio de uma sequência de transações locais, cada uma publicando um evento. Se uma etapa falhar, transações compensatórias desfazem as etapas anteriores.

Duas variantes:

• Coreografia: Serviços reagem a eventos autonomamente (descentralizado)
• Orquestração: Um Orquestrador de Saga central coordena as etapas (centralizado)

Quando usar:

• Fluxos de trabalho multi-serviço onde ACID entre serviços é impossível
• Transações de negócios de longa duração (pedido → pagamento → inventário → envio)
• Necessidade de rollback entre limites de serviço

Exemplo de Coreografia:

OrderService creates order →
  [event: OrderCreated] →
    PaymentService charges card →
      [event: PaymentProcessed] →
        InventoryService reserves stock →
          [event: StockReserved] →
            ShippingService books courier

Transações Compensatórias (em caso de falha):

ShippingService fails →
  [event: ShippingFailed] →
    InventoryService releases stock →
      PaymentService refunds card →
        OrderService marks order failed

Trade-offs:

• ✅ Sem bloqueio distribuído; alta disponibilidade
• ✅ Escala bem entre serviços
• ❌ Difícil de depurar; rastreamento distribuído necessário
• ❌ Transações compensatórias são complexas de implementar corretamente

4. Circuit Breaker

O que é: Um proxy que monitora chamadas para um serviço. Se a taxa de falha exceder o limite, o circuito "abre" e as chamadas falham rapidamente em vez de esperar pelo timeout.

Estados:

CLOSED  → calls pass through; monitor failure rate
OPEN    → calls fail immediately; no calls to downstream
HALF-OPEN → let a probe call through; if success, close; if fail, stay open

Quando usar:

• Chamando qualquer serviço externo (gateway de pagamento, SMS, e-mail)
• Microsserviços chamando uns aos outros
• Prevenindo cascata de timeouts quando o serviço downstream está lento

Ferramentas de implementação: Hystrix (descontinuado), Resilience4j, Polly (.NET), Envoy proxy

Limiares (ponto de partida):

• Abre após 50% de taxa de falha em 10 requisições
• Permanece aberto por 30 segundos
• Meio aberto: permite 1 requisição de teste

Trade-offs:

• ✅ Previne falhas em cascata
• ✅ Dá tempo para o serviço downstream se recuperar
• ❌ Adiciona overhead de latência para monitoramento
• ❌ Requer comportamento de fallback quando o circuito está aberto

5. Bulkhead

…