O banco de dados que só fica lento depois que o produto dá certo

No lançamento o sistema voava; seis meses depois, cada tela arrasta. Quase nunca é falta de servidor: é código que conversa errado com o banco. O que um squad sênior olha antes de você trocar de infraestrutura no escuro.

Tem uma frase que eu escuto quase toda semana, sempre com o mesmo tom de surpresa: "no lançamento o sistema voava, agora ele trava". Da última vez veio de um e-commerce de nicho, time de umas 40 pessoas, que procurou a Revin pedindo uma segunda opinião sobre um produto que outro fornecedor tinha construído. A tela de pedidos, que abria num piscar de olhos quando o site subiu, estava levando 14 segundos pra carregar. Ninguém tinha tocado no código havia meses. O que mudou foi o tamanho do banco.

A leitura fácil é culpar a infraestrutura. "Falta servidor", "o Postgres não aguenta". Quase nunca é isso. Na maioria das vezes que a Revin abre o capô de um produto assim, o servidor está entediado, com a CPU em 12%, esperando um código que conversa errado com o banco de dados.

E o pior é que esse defeito é invisível exatamente quando você mais precisaria enxergá-lo: no dia da entrega, com os dados de teste, tudo funciona lindamente.

Gráfico num monitor: consultas que eram planas no lançamento viram picos conforme os dados crescem.

Por que a demo nunca mostra isso?

Na demo, o banco tem 200 registros. Talvez 500. Com 500 linhas, qualquer coisa é rápida. Você pode escrever a consulta mais preguiçosa do mundo, sem um único índice, que o banco varre a tabela inteira em menos de um milissegundo e ninguém percebe.

O clássico é o que os engenheiros da Revin chamam de problema N+1. A tela lista 50 pedidos e, pra cada pedido, o código dispara uma consulta nova pra buscar o cliente. Depois outra pra buscar os itens. Os seus 50 pedidos viram 101 idas ao banco, às vezes 150. Com o seed de teste isso acontece rápido demais pra você notar. Em produção, com a tabela cheia e a rede no meio do caminho, cada ida custa. Multiplica.

O ORM ajuda a esconder o crime. Uma linha inocente que parece só "pega o cliente desse pedido" é, na real, uma consulta ao banco disparada dentro de um loop. O dev que escreveu não vê a consulta. O founder que aprovou a demo, muito menos.

A conta que cresce junto com o sucesso

Aqui está a parte cruel. Enquanto o produto não decola, ninguém sente nada. O banco tem pouca coisa, as consultas ruins passam despercebidas, e o fornecedor te entrega tudo "no prazo, funcionando". A fatura do design ruim só chega quando o produto começa a dar certo.

No e-commerce que contei lá em cima, a tela de pedidos fazia mais de 1.200 consultas ao banco pra montar uma única página. Com 300 pedidos no início, ninguém reclamou. Quando o catálogo cresceu e eles passaram dos 38 mil pedidos, a mesma tela virou aquele pesadelo de 14 segundos e o suporte começou a ouvir "o site travou" o dia inteiro. Faço uma ressalva honesta sobre esse número: quem me procura já está no pior dia, então minha amostra é enviesada pra tragédia. Mesmo assim, o padrão se repete tanto que virou quase um roteiro.

Ou seja: o teste de verdade do seu software não é o lançamento. É o sexto mês, quando ele deu certo o suficiente pra ficar lento.

Corredor de data center: na maioria das vezes o problema não está aqui, e sim em como o código pede os dados.

Se a sua tela mais usada começou a arrastar conforme a base cresceu, vale um diagnóstico técnico antes de comprar mais servidor. Dá pra começar por um Diagnostic Sprint da Revin.

O que um squad sênior olha antes de você reclamar

Perguntei pros engenheiros da Revin o que eles olham nesses casos e a resposta foi quase decepcionante de tão básica. Não tem mágica. Tem uma disciplina que a maioria pula porque dá trabalho e não aparece na demo.

• Rodar EXPLAIN ANALYZE nas consultas das telas mais acessadas. É o comando que mostra, sem achismo, se o banco está varrendo a tabela inteira ou usando um índice.
• Ligar o log de queries em desenvolvimento pra caçar N+1. Se uma tela dispara 80 consultas pra montar uma lista, tem algo errado ali.
• Criar índice onde a busca dói, e só onde dói. Índice demais também custa caro na escrita e no armazenamento.
• Testar com volume de produção, não com o seed de 200 linhas. Popular o banco com um milhão de registros falsos e ver o que quebra antes do cliente ver.
• Definir um orçamento: nenhuma tela crítica passa de X consultas ou Y milissegundos. E medir isso a cada release, não uma vez só.

Nada disso é ciência de foguete. Mas repare que todo esse trabalho acontece hoje pra evitar um problema que só aparece daqui a seis meses, quando o fornecedor barato já sumiu com o pagamento. É por isso que, na Revin, performance de banco entra na definição de pronto desde o primeiro sprint. Um squad sênior embarcado paga essa conta enquanto ela ainda é barata.

Quer ver como isso aparece num caso real? Alguns dos nossos cases mostram o antes e o depois desse tipo de gargalo.

O índice que valia 9 segundos

Voltando ao e-commerce. A correção mais impactante que a Revin fez na primeira semana foi ridícula de simples: um índice que faltava numa coluna de data. Uma consulta que levava 9 segundos passou a responder em 40 milissegundos. Não houve reescrita nem servidor novo. Houve alguém olhando o EXPLAIN que ninguém tinha olhado.

Vou ser justa com o outro lado: se você tem um MVP de três telas ainda procurando os dez primeiros clientes, otimizar índice agora é perfumaria. Nesse estágio o seu desafio é achar quem pague; escalar banco é problema pra muito depois. Contrata alguém rápido, lança feio e segue. O índice vira urgente no dia em que o produto começa a dar certo, e é justamente esse dia que o fornecedor barato não planejou pra você.

Se o seu sistema já passou desse estágio e começou a arrastar, não troca de servidor no escuro. Marca uma conversa com a Revin e a gente olha o que o banco está tentando te dizer.