Análise de performance: o checklist que uso antes de sugerir reescrita
Antes de aprovar uma reescrita cara, passe por este checklist. Seis verificações que, na maioria dos casos, encontram o gargalo sem trocar uma linha de linguagem.
Quando alguém diz "o sistema está lento, vamos reescrever", a reescrita raramente é a resposta certa — é a mais cara e a mais arriscada. Antes de aprovar meses de trabalho e o risco de um cutover, eu passo por um checklist. Na maioria absoluta dos casos, ele encontra três a cinco causas concretas que explicam o grosso do problema, e nenhuma delas exige trocar de linguagem.
1. Os índices estão sendo usados nas queries mais lentas?
Primeira parada, sempre, porque é onde mora a maioria dos gargalos. Pegue as queries mais lentas (o log de slow queries do banco já entrega) e rode EXPLAIN ANALYZE. Procure por Seq Scan em tabelas grandes — significa que o banco está lendo a tabela inteira por falta de índice. Um índice no lugar certo pode transformar uma query de segundos em milissegundos. Cuidado também com índices que existem mas não são usados porque a query não bate com a coluna indexada.
2. Existe N+1 no ORM?
O segundo suspeito mais comum, e o mais traiçoeiro porque o ORM o esconde. Listar 100 itens e, para cada um, buscar um relacionamento, dispara 101 queries em vez de duas. Logue a contagem de queries por requisição. Se uma página simples dispara dezenas ou centenas de queries, você achou o problema. A correção — eager loading, join, ou um batch — costuma ser de poucas linhas e devolve um ganho enorme.
3. O cache de sessão e autenticação está funcionando?
Toda requisição autenticada que vai ao banco validar sessão e permissões a cada chamada está pagando um custo desnecessário. Verifique se sessão, dados de autenticação e permissões estão em cache (Redis, por exemplo) com invalidação correta. Em sistemas com muito tráfego, esse é um dos wins mais rápidos: aliviar o banco da carga de auth repetida.
4. Os payloads de API estão inchados?
APIs que retornam objetos enormes — campos que ninguém usa, relacionamentos aninhados em profundidade, listas sem paginação — gastam tempo serializando, banda transmitindo e tempo no cliente desserializando. Verifique o tamanho das respostas das rotas mais usadas. Paginação, seleção de campos e compressão (gzip/brotli) frequentemente cortam o tempo de resposta sem tocar na lógica.
5. O pool de conexões está bem configurado?
Um pool pequeno demais faz as requisições esperarem por uma conexão livre — latência sobe sem que a CPU suba, porque o processo só está esperando. Um pool grande demais sobrecarrega o banco. Verifique o tamanho do pool contra a concorrência real e monitore conexões em uso versus disponíveis. Esse é um daqueles ajustes de uma linha que, no contexto certo, muda o comportamento sob carga.
6. Os assets estão comprimidos e atrás de CDN?
Para a parte web, antes de culpar o backend: os assets estáticos (JS, CSS, imagens) estão comprimidos, com cache headers corretos e servidos por uma CDN? LCP alto muitas vezes é assets pesados e mal cacheados, não uma API lenta. Imagens em WebP/AVIF, bundle dividido e CDN resolvem boa parte dos problemas de Core Web Vitals sem reescrever nada.
Como usar o checklist
A regra é medir, não adivinhar. Cada item acima deve produzir um número — antes e depois. Conserte os que aparecerem, meça de novo, e repita. Quase sempre, três a cinco desses seis pontos explicam 80% da lentidão, e corrigi-los devolve a maior parte do desempenho por uma fração do custo de uma reescrita.
Vale lembrar o caso clássico: um cliente queria reescrever em Go o módulo de relatórios de vendas de um SaaS de varejo por causa de lentidão que crescia com o intervalo dos relatórios e sangrava para as inserções; o problema era fragmentação de índice por UUIDs aleatórios, corrigida com uma migração para UUID v7 em bancos distribuídos com bilhões de registros — +260% de throughput, zero linha de linguagem trocada. A reescrita teria custado meses e não tocaria na causa.
Quando, então, reescrever?
Há casos legítimos: stack obsoleta sem suporte de segurança, arquitetura tão acoplada que impede otimização incremental, ou um gargalo CPU-bound puro que a linguagem realmente limita. Mas mesmo nesses, o checklist vem antes — porque ele transforma "acho que precisamos reescrever" em "sabemos exatamente onde está o problema e por que a reescrita é (ou não é) a resposta". Diagnóstico antes de cirurgia, sempre.