Resiliência em APIs: como decidir, implementar e provar que está funcionando

Palestra feita no evento TDC São Paulo no dia 18 de Setembro de 2025 na trilha de API e Microsserviços.

Transcript

1. Resiliência em APIs: MÔNICA RIBEIRO como decidir, implementar e provar que está funcionando
2. Será que a minha API é de fato resiliente, ou só parece?
3. Agenda O que é resiliência? INTRODUÇÃO PADRÕES & OBSERVABILIDADE RESUMÃO Guia rápido para organizar seus próximos passos Retry, Circuit Breaker, Rate Limiting
4. Hello world :) Mônica Ribeiro Backend Dev Specialist @ Zup Innovation
5. “Resiliência é a habilidade de um sistema de se adaptar a falhas, se recuperar e continuar operando sem colapsar.” 📖 Release It! Design and Deploy Production-Ready Software (Michael Nygard, 2018)
6. ALTA DISPONIBILIDADE TOLERÂNCIA A FALHAS RESILIÊNCIA minimiza downtime continua funcionando mesmo se parte do sistema falhar recupera-se rapidamente e mantém serviço útil sob falha 📖 Netflix Tech Blog: Making the Netflix API More Resilient (2012). alguns conceitos próximos
7. falsa sensação de segurança cuidado com a
8. parece resiliência mas não é... 📖 Google SRE Book (Site Reliability Engineering, 2016): capítulo Managing Overload RETRIES SEM CONTROLE TIMEOUTS PADRÃO CLUSTERS SEM DEGRADAÇÃO PLANEJADA criam retry storm e derrubam o serviço mais rápido. podem ser altos demais, aumentando latência e fila. ficam indisponíveis em cascata.
9. graceful degradation
10. padrões de resiliência + métricas retry circuit breaker rate limit
11. retry
14. retry storm!
16. exponential backoff + jittery
17. retry Basicamente: uma nova tentativa automática de executar uma operação que falhou. Útil para falhas transitórias (ex.: timeout, erro de rede, falha temporária do serviço)
18. retry Chamadas idempotentes Quando a experiência do usuário pode se beneficiar de nova tentativa sem intervenção manual Erros temporários e intermitentes (ex.: timeout, erro de rede, falha temporária do serviço) quando usar Chamadas não idempotentes (ex.: POST que cria recurso → pode gerar duplicidade) Serviços que já estão sob alta carga (risco de criar retry storm) Erros permanentes (ex.: erro de autenticação, input inválido) quando NÃO usar
19. retry retry.count (quantos retries foram feitos) retry.success.count (quantos tiveram sucesso depois do retry) retry.failed.count (quantos falharam mesmo após retry) latency.p95 (para garantir que o retry não está aumentando demais a latência) metrificando
20. Grafana
21. circuit breaker
24. 📖 CLOSED OPEN HALF- OPEN
25. 📖 CLOSED OPEN HALF- OPEN Sucesso
26. 📖 CLOSED OPEN HALF- OPEN Sucesso taxa de falha acima do limite
27. 📖 CLOSED OPEN HALF- OPEN Sucesso após um período, tenta novos processamentos taxa de falha acima do limite
28. 📖 CLOSED OPEN HALF- OPEN Sucesso taxa de falha abaixo do limite taxa de falha acima do limite após um período, tenta novos processamentos taxa de falha acima do limite
30. circuit breaker "A função do Circuit Breaker é permitir que falhas se manifestem rapidamente e que o sistema se recupere de forma segura." 📖 Release It! Design and Deploy Production-Ready Software (Michael Nygard, 2018)
31. circuit breaker Dependência externa instável ou com latência alta Serviço crítico pode sofrer efeito dominó Necessidade de proteger o throughput do seu sistema Quando você tem uma estratégia clara de fallback quando usar Em chamadas internas extremamente rápidas e confiáveis Para fluxos onde a falha deve sempre ser tentada até o fim Quando o custo de abrir o circuito é maior que o de falhar Em sistemas sem fallback viável quando NÃO usar
32. circuit breaker circuit.breaker.state (estado atual do circuito) circuit.breaker.open.count (número de vezes que o circuito foi aberto) circuit.breaker.half_open.success.count (sucessos durante o estado half-open) circuit.breaker.half_open.failure.count (Falhas durante o estado half- open) metrificando
33. circuit breaker circuit.breaker.rejected.requests.count (requisições bloqueadas pelo circuito) circuit.breaker.execution.time (histograma - tempo de execução das requisições quando o circuito está fechado) circuit.breaker.fallback.count (número de vezes que o fallback foi acionado) error.rate (por dependência - % de falhas que disparam o Circuit Breaker) metrificando
34. Grafana
35. Grafana
36. rate limiting
37. rate limiting Quando há risco de sobrecarga acidental ou maliciosa (DoS, loops, etc) Para proteger recursos sensíveis (como serviços de terceiros pagos por volume) Para aplicar fairness (por exemplo, não deixar um único cliente monopolizar sua API) Para proteger backend ou serviços internos que não foram feitos para aguentar tráfego massivo Para garantir limites de planos em APIs públicas (ex: usuários free vs. premium) quando usar
38. rate limiting token bucket o
39. rate limiting fixed window
40. rate limiting sliding window
41. rate limiting rate.limit.requests.blocked rate.limit.requests.allowed % blocked (percentual de bloqueio — alto demais pode significar que o limite está mal configurado) latency.p95 (para garantir que o rate limiting não está criando gargalos) metrificando
42. próximos passos DECISÃO CONSCIENTE CONFIGURAÇÃO ADEQUADA FALLBACKS CLAROS MÉTRICAS EXPOSTAS ALARMES ATIVOS você sabe quais padrões de resiliência usa e por quê thresholds, timeouts e backoff revisados quando algo falha, você tem plano B você sabe medir o sucesso do padrão e seu time é avisado quando algo sai do esperado
43. 📖 Uwe Friedrichsen
44. 📖 Essencialismo - Greg McKeown
45. Obrigada pelo seu tempo