Ao longo do tempo, com sistemas rodando de verdade, usuários usando, integrações acontecendo e volume crescendo, alguns erros deixam de ser teóricos e passam a ter impacto real. Não são erros de sintaxe ou de framework. São erros de decisão, de suposição e, principalmente, de experiência.

Compartilhar esses erros não é exposição. É maturidade técnica.

Um dos primeiros erros que cometi foi assumir que o “funciona local” era suficiente. O sistema atendia aos requisitos, passava nos testes básicos e parecia estável. O problema é que produção adiciona concorrência, latência, falhas externas e volume. Coisas que simplesmente não existem no ambiente local. Aprendi cedo que testar comportamento é diferente de testar contexto.

Outro erro recorrente foi confiar demais em serviços externos. APIs de terceiros pareciam estáveis até o dia em que começaram a responder lentamente ou falhar intermitentemente. Sem timeout bem definido, sem fallback e sem isolamento, o problema externo se transformou em indisponibilidade interna. A lição aqui foi clara: dependência externa precisa ser tratada como ponto de falha, não como extensão do seu sistema.

Também já subestimei o impacto da concorrência. Processos rodando em paralelo, filas consumidas por múltiplos workers e requisições simultâneas expuseram condições de corrida que nunca apareceram em teste. Duplicidade de execução, dados inconsistentes e comportamentos estranhos surgiram sem aviso. Foi aí que aprendi, na prática, que idempotência não é detalhe, é requisito.

Houve momentos em que cache foi usado como solução rápida, sem critério. Funcionou no início, melhorou performance, mas criou uma nova classe de problema: inconsistência. Dados desatualizados começaram a aparecer e o esforço para entender se o problema estava no código, no banco ou no cache aumentou bastante. Cache resolveu o sintoma, mas atrasou o diagnóstico da causa real.

Outro erro comum foi logar pouco ou logar demais. Logs insuficientes tornam qualquer incidente uma investigação no escuro. Logs excessivos, por outro lado, dificultam encontrar o que realmente importa. Com o tempo, aprendi que log bom é aquele que ajuda a responder perguntas, não o que registra tudo.

Já deixei passar também a importância de monitorar comportamento, não só infraestrutura. CPU e memória estavam normais, mas usuários reclamavam de lentidão. O problema não era recurso, era fluxo. A partir daí, ficou claro que disponibilidade e latência percebida dizem muito mais sobre a saúde do sistema do que gráficos isolados.

Em alguns momentos, tomei decisões de arquitetura rígidas cedo demais. Abstrações complexas criadas “pensando no futuro” acabaram dificultando mudanças simples. Arquitetura precisa dar suporte à evolução, não impedir. Esse tipo de erro não quebra o sistema imediatamente, mas cobra juros altos com o tempo.

Por fim, talvez o erro mais sutil tenha sido não tratar operação como parte do desenvolvimento. Código foi escrito pensando em funcionalidade, não em manutenção, observabilidade ou resposta a incidentes. Produção mostrou que escrever código é apenas uma parte do trabalho. Operar o sistema é a outra metade.

O que ficou de aprendizado

Produção não perdoa suposições. Ela expõe decisões frágeis, atalhos técnicos e falta de preparo. Cada erro deixou uma lição clara: sistemas precisam ser pensados para falhar, para escalar e para serem operados por pessoas reais.

Errar faz parte. Repetir os mesmos erros é escolha.

The post Erros que já cometi em produção (e o que aprendi com eles) appeared first on Leonardo Nascimento | Engenheiro de Software.