O "happy path" passou na demo e quebrou no primeiro erro real
Semana passada revisei um endpoint de pagamento que "estava pronto". Na demo funcionava: request entrava, retornava 200, tela verde. Aí eu derrubei o gateway de propósito e a aplicação devolveu 500 com stacktrace na resposta, deixou o pedido num estado intermediário e não escreveu nada no log.
Isso é o que a piada velha dos Bell Labs chama de regra dos 90-90: os primeiros 90% do código levam 90% do tempo, e os 10% finais levam os outros 90%. O "happy path" é o barato. O que come tempo é o resto, e é justamente o resto que não aparece numa demo.
O teste rápido pra saber se um trecho está mesmo pronto é forçar o que não devia acontecer:
# com o serviço de pagamento parado, dispara o fluxo
curl -X POST localhost:3000/checkout -d @payload.json
Se a resposta for stacktrace, estado inconsistente ou silêncio no log, faltam os 10%.
Um checklist do que costuma ficar de fora (serve como definição de pronto):
- Caminhos de erro: timeout, dependência fora, payload malformado, cada um com resposta tratada e o código HTTP certo.
- Idempotência: o mesmo POST duas vezes (retry do cliente) não pode cobrar duas vezes.
- Migração de dados: os dados velhos são sempre mais sujos do que o esperado. Rode a migração contra uma cópia de produção, não contra um seed limpo.
- Observabilidade: log estruturado no ponto de falha, métrica de erro por rota, alerta que dispara sem o cliente precisar reclamar.
- Carga: p95 sob concorrência real, não a latência da sua máquina com um request só.
Nenhum desses aparece na tela bonita. Todos aparecem em produção. Cronometrar só o "happy path" e esquecer os 10% finais é medir só a parte fácil da prova.
Versão completa, com o lado de negócio da história, no blog: https://revin.com.br/pt/blog/o-prazo-que-ganha-o-contrato-e-o-que-mais-atrasa