9. Resiliência e Caos

Às 10:00 a venda relâmpago abre e o provedor de pagamento, sob a carga de todos os sites de ingressos do país, começa a responder em três segundos em vez de trezentos milissegundos. Nada está "fora do ar". Mesmo assim, em um minuto o order para de responder qualquer coisa — até o GET /orders/{id}, que nunca fala com o provedor —, porque todas as suas threads estão esperando o payment. Este lab reproduz essa falha no seu laptop e aplica os padrões da aula de confiabilidade, com um número para cada um.

Este lab constrói no BoxOffice o capítulo 10 da história do curso: a falha em cascata e as suas defesas — timeout, retry com jitter, circuit breaker e bulkhead —, depois um game day. Ele vem logo depois do lab 8 de propósito: caos exige observabilidade antes, então todo experimento é acompanhado no dashboard do lab 8 e aciona o alerta de burn rate dele.

Slides

Clique nos slides e use ← → para navegar; F abre em tela cheia e P abre a visão do apresentador, com as notas. Abrir os slides em uma nova aba

Antes de começar

Todo comando roda na raiz do seu repositório boxoffice, no estado em que o lab 8 o deixou:

boxoffice/
├── docker-compose.yaml     # labs 1-8: ... kafka, order, notification, otel-lgtm (+ x-otel anchor)
├── infra/                  # nginx/, postgres/, pgbouncer/, grafana/, otel/
├── load/  scripts/
└── services/
    ├── auth/  catalog/  gateway/  inventory/  notification/
    └── order/              # outbox with traceparent (lab 8)

Todo arquivo deste lab aparece completo nestas páginas e é publicado em https://insper.github.io/platform/2027.1/hands-on/9/code/<caminho>.

Arquitetura

flowchart LR
    k6[k6: pay + browse] --> order["order (Resilience4j)"]
    order -->|"timeout · retry · breaker · bulkhead"| tp1["toxiproxy: payment"]
    tp1 --> payment[payment]
    payment -->|"timeouts, Idempotency-Key"| tp2["toxiproxy: psp"]
    tp2 --> psp["psp (WireMock)"]
    gm[mestre do jogo] -.->|"latência, reset, queda"| tp1
    gm -.-> tp2
    order -.->|OTLP| lgtm[otel-lgtm]
    payment -.->|OTLP| lgtm

O que você vai medir

Pré-requisitos

• Labs 7 (o serviço order) e 8 (dashboards e alertas) concluídos.
• Leia a aula de confiabilidade: padrões de resiliência e engenharia do caos.

Passos

1. Pagamento, provedor e Toxiproxy — o adaptador idempotente payment, um provedor WireMock, os proxies do Toxiproxy e o seu primeiro toxic.
2. Padrões de resiliência — reproduza a cascata, depois adicione timeout, retry, circuit breaker e bulkhead, um de cada vez.
3. Game day — papéis, hipóteses, falhas escondidas, linha do tempo e uma revisão sem culpados.
4. Meça — o script do k6 com um cenário pay e um browse, e a tabela de resultados.

Experimente no playground

Experimente: em cascading-failure, rode o perfil load e aumente a latência do nó de terceiro (3rd party): veja a utilização do app server chegar a 100% e os erros dele se espalharem para todas as requisições. Depois defina um timeout e ative o circuit breaker na aresta para o terceiro, e rode de novo. Em retry-storm, compare retries: 3 com e sem backoff exp+jitter durante uma queda.

O simulador completo está no playground.

Meça

O passo Meça tem o script do k6, os comandos e a tabela de resultados para guardar em results/lab9.md; as revisões do game day vão para results/lab9-gameday.md.

Solução de problemas

Limpeza

curl -s -X POST localhost:8474/reset    # no toxic left behind
docker compose stop                     # keep the stack for lab 10's images
docker compose down -v                  # or remove everything

Estado final

boxoffice/
├── docker-compose.yaml     # + psp, toxiproxy, payment; order -> toxiproxy:18085 + PAYMENT_* knobs
├── infra/
│   ├── grafana/alerting/slo-order.yaml   # the lab 8 burn-rate alerts, for order (game day)
│   ├── psp/mappings/charge.json
│   └── toxiproxy/toxiproxy.json
├── load/pay-under-chaos.js
├── scripts/game-day.sh
├── results/lab9.md, lab9-gameday.md
└── services/
    ├── order/              # pom (+ resilience4j, aspectj), application.yaml, OrderService,
    │                       # OrderController (+ /pay), payment/ package
    └── payment/            # new: idempotent adapter to the provider (+ Dockerfile, .dockerignore)

Faça commit e tag: git add -A && git commit -m "lab 9: resilience" && git tag lab9.

Checklist

• payment, psp e toxiproxy rodam no docker-compose.yaml; order e payment chegam às suas dependências pelo Toxiproxy
• o POST /payments é idempotente pela Idempotency-Key, e a chave é repassada ao provedor
• o POST /orders/{id}/pay confirma o pedido (status CONFIRMED + OrderConfirmed no outbox) e é protegido por timeout, retry, circuit breaker e bulkhead
• a execução sem proteção mostra a cascata (browse degradado); a execução de cada padrão mostra o seu efeito, em números
• um game day com pelo menos três experimentos escondidos, uma linha do tempo e uma revisão sem culpados por rodada
• tabela de resultados preenchida em results/lab9.md e explicada
• autoverificação: curl -s -X POST localhost:8474/reset, depois PAYMENT_RESILIENCE=true docker compose up -d --wait order, e uma chamada pay devolve CONFIRMED; push com a tag lab9

Relacionados

• Teoria: Confiabilidade · SLOs e orçamentos de erro · Padrões de resiliência · Engenharia do caos · Integrações externas
• Estudo de caso: Sistema de pagamentos
• Projeto: Game day de caos
• Próximo lab: 10. Kubernetes adiciona autocura e autoscaling.

Começar: Pagamento, provedor e Toxiproxy