Resolva na ordem — os níveis constroem uns sobre os outros. Tente resolver sem consultar a solução. Os marcados com 🔥 são os mais formativos.
Nível 1 — Conceitual
1. Latência vs throughput. Explique, com suas palavras, por que dobrar o número de servidores não reduz a latência média de uma requisição. Dê um exemplo do mundo real.
2. Cinco noves. Estime o orçamento de erros (em segundos) de um sistema com 99,99% de disponibilidade num mês de 30 dias. Quanto é em horas? Em segundos?
3. 🔥 Encontre o gargalo. Dado o cenário — sua API responde em 500ms, sendo 50ms na sua app, 350ms numa query SQL e 100ms numa chamada a serviço externo — onde você otimiza primeiro? Por quê?
Nível 2 — Prático
4. Timeouts. Pegue um projeto seu (qualquer linguagem) que faça chamadas HTTP. Confira toda chamada externa. Tem timeout? Se não tem, adicione. Documente o que encontrou.
5. 🔥 Retry com backoff. Implemente em Go (ou outra linguagem) uma função retryWithBackoff(fn, maxAttempts) com exponential backoff e jitter. Escreva testes que validem o backoff acontecendo.
6. 🔥 Circuit breaker manual. Sem usar biblioteca, implemente um circuit breaker simples (CLOSED/OPEN/HALF-OPEN) com testes unitários. Sim, é trabalhoso. Sim, vai te ensinar mais que ler 10 artigos.
Nível 3 — Carga e Profiling
7. Load test caseiro. Pegue uma API qualquer (até httpbin.org/get serve, com cuidado), escreva um teste k6 com 3 estágios (rampa, sustentação, descida) e thresholds. Rode e analise.
8. 🔥 Profiling em Go. Num programa Go simples, escreva uma função propositalmente ineficiente (ex: concatenação de strings num loop usando +). Use pprof pra identificar o problema, refatore (use strings.Builder), e compare os profiles antes/depois.
Nível 4 — Resiliência e Caos
9. Cenário pós-mortem. Desenhe (texto ou diagrama) como três falhas diferentes podem derrubar uma API simples sem resiliência. Para cada uma, indique qual padrão (timeout/retry/circuit breaker/bulkhead/fallback) mitigaria.
10. 🔥 GameDay solo. Suba o projeto guiado da seção 7. Sem aviso prévio (faça num dia que você não esperava), introduza UMA falha aleatória via Toxiproxy. Depois, observe só pelas métricas (não olhe os logs primeiro): você consegue identificar o problema só pelo dashboard? Se não, melhore os dashboards.
Bônus
- Liste, do seu projeto atual no trabalho:
- Qual a SLO declarada (se existe)?
- Quais são os "Quatro Sinais Dourados" sendo monitorados?
- Quais alertas estão configurados? Algum é ruidoso?
- Quando foi a última vez que alguém da equipe fez retry de coisa não idempotente?
Se você respondeu "não sei" pra duas ou mais perguntas... bem-vindo à realidade da maioria dos backends. Agora você sabe o que melhorar.