Porque escalar parte as apps feitas com vibe coding

O que é e porque importa

Uma app feita com o Claude Code funciona lindamente contigo e com três amigos. Depois chegam cem pessoas ao mesmo tempo e as páginas demoram uma eternidade, ou nem abrem.

O motivo normalmente não é o servidor pequeno. É a forma como a app fala com a base de dados. Com poucos dados e poucos utilizadores, cada desperdício custa milissegundos. Com muitos dados e muita gente ao mesmo tempo, os desperdícios somam-se.

O teste de carga serve para veres isso antes: simulas muitas pessoas ao mesmo tempo, medes quanto demora cada página e descobres o que se parte. Tu antes dos teus utilizadores.

Regra número um, sem exceções: o teste faz-se numa cópia do projeto ou no ambiente de testes (staging), com dados falsos. Nunca na base de dados com os dados reais, nunca no site em produção. Um teste de carga é um pequeno ataque: no site real tornas a app lenta ou deita-la abaixo para quem a está a usar.

1. Prepara o sítio certo

Antes de escrever o prompt, garanto três coisas.

1. Tenho uma cópia separada: um ambiente de testes, ou o projeto no meu computador com uma base de dados só sua.
2. Fiz um commit com git, para poder voltar atrás.
3. Sei que serviços externos a app usa (pagamentos, email, notificações, APIs de outros). No teste não podem ser chamados a sério.

Sobre o último ponto: um teste de carga contra um site ou uma API que não são teus pode violar as condições de utilização deles. Testa só o teu próprio ambiente de testes. Para começar, peço ao Claude que verifique:

Antes de mais, verifica a que base de dados e a que serviços externos o projeto está ligado neste momento. Se alguma coisa aponta para os dados reais ou para produção, para e diz-me. Quero fazer o teste só numa cópia, com dados falsos, e com os serviços externos substituídos por versões falsas.

2. O teste com mil utilizadores falsos

Depois, no Claude Code, escrevo isto:

Faz um teste com mil utilizadores falsos e diz-me o que se parte. Enche a base de dados de testes com dados falsos realistas, escreve um script que simule mil pessoas nas páginas principais ao mesmo tempo (usa uma ferramenta gratuita e open source, por exemplo k6, Locust ou Artillery) e mede quanto demora cada página. Dá-me as três páginas mais lentas, o motivo e a correção que propões. Não mexas no código até eu dizer ok.

O que acontece, na prática. O Claude enche a base de dados de testes com muitas linhas falsas mas credíveis: utilizadores, encomendas, produtos. Isto conta mais do que parece: com dez linhas tudo é rápido, os problemas só aparecem com volumes realistas.

Depois escreve um script que envia pedidos às páginas principais como se fossem muitas pessoas ao mesmo tempo. k6, Locust e Artillery são três ferramentas gratuitas e open source que fazem exatamente isso: deixa o Claude escolher conforme o projeto.

A última frase é a mais importante: primeiro quero perceber, depois decido. O script do teste e os dados falsos tem de os criar, o código da app não.

Para uma garantia extra enquanto ele te propõe as correções, usa o plan mode: Shift+Tab até veres «plan mode on» em baixo, ou /plan no início da mensagem. Aí o Claude lê e propõe, mas não altera ficheiros até aprovares o plano. Para o teste em si, fica de fora: ele tem de criar o script e os dados falsos.

Mil de uma vez ou por patamares

Mil pessoas ao mesmo tempo são muitas, até para o computador que gera o teste. Mais vale subir por patamares e ver a partir de quando as páginas ficam lentas. E o ambiente de testes costuma ser mais pequeno do que o real: o que conta é o antes e o depois, não o número absoluto.

Faz o teste por patamares: primeiro 50 utilizadores, depois 200, depois mil. Para cada patamar diz-me o tempo médio, o tempo dos pedidos mais lentos e a partir de quando começam os erros.

Uma correção de cada vez

Quando te der a lista das três páginas mais lentas, não lhe peças para arranjar tudo de uma vez. Escreve:

Corrige a primeira, repete o teste e diz-me os tempos antes e depois.

E assim por diante com a segunda e a terceira. Se corriges tudo de uma vez e depois alguma coisa melhora, ou piora, não sabes o que foi.

3. As três coisas que resolve quase sempre

Quando uma página está lenta, o motivo é quase sempre um destes três.

Cem perguntas em vez de uma

Uma página mostra 100 produtos. O código primeiro pede à base de dados a lista de produtos e depois, para cada um, pede o preço. Total: 101 perguntas à base de dados para uma só página. Chama-se «problema N+1»: uma pergunta para a lista, mais uma por cada elemento.

Sozinho não dás por isso. Com mil pessoas passam a ser cem mil perguntas, e a base de dados entope. E muitas vezes o código parece limpo: o problema está por trás.

A correção é pedir tudo junto: uma só pergunta que traga produtos e preços, ou duas no máximo (a lista e depois todos os preços de uma vez). Pede:

Encontra as consultas dentro de um ciclo e transforma-as numa só.

Tabelas sem índices

Pensa no índice remissivo no fim de um livro. Sem ele, para encontrar uma palavra folheias as páginas todas. A base de dados faz o mesmo: sem índice, para encontrar as encomendas de um utilizador lê-as todas, uma a uma. Com o índice vai direta.

Normalmente o id principal de cada tabela já tem o seu índice. As colunas que usas para procurar, filtrar e ligar tabelas, muitas vezes não. Pede:

Adiciona índices nas colunas que usas para procurar, filtrar e ordenar (id do utilizador, email, data).

Mas os índices não são de graça: ocupam espaço e tornam as escritas um pouco mais lentas, porque a cada dado novo a base de dados atualiza também o índice. Só se põem onde fazem falta. Eu peço sempre a prova:

Para cada índice que adicionares, diz-me que página ou consulta o usa e mostra-me o tempo antes e depois. Se um índice não serve para nada, não o adiciones.

Dados recarregados todas as vezes

A tabela de preços ou o menu que mudam uma vez por dia não têm de ser pedidos à base de dados em cada visita. Guardam-se em memória durante uns minutos: é a cache.

Põe em cache os dados que mudam raramente e diz-me ao fim de quanto tempo se atualizam.

A cache também tem um preço: os dados podem estar desatualizados. Se mudares um preço e a cache durar dez minutos, durante dez minutos alguém vê o antigo. Por isso tens de saber ao fim de quanto tempo se atualizam. E os dados pessoais de um utilizador não podem ir parar a uma cache partilhada, senão outra pessoa arrisca-se a vê-los.

Verifica que na cache não há dados pessoais de um utilizador que outro utilizador possa ver.

Atenção se a app corre num alojamento serverless: aí o código corre em muitas instâncias que se ligam e desligam sozinhas. A memória de uma instância não é partilhada com as outras e esvazia-se muitas vezes, por isso uma cache guardada aí serve de pouco. É preciso uma cache partilhada, por exemplo Redis. Pergunta ao Claude qual oferece o teu alojamento:

A app corre num alojamento serverless? Se sim, diz-me que cache partilhada oferece o meu alojamento e usa essa em vez da memória do servidor.

Os erros mais comuns

• Fazer o teste no site real ou na base de dados com os dados reais. Faz-se sempre numa cópia ou no ambiente de testes, com dados falsos.
• Testar com a base de dados quase vazia. Enche-a com dados falsos em quantidades realistas.
• Corrigir tudo de uma vez. Uma correção de cada vez, com os tempos antes e depois.
• Pôr índices em todas as colunas. Só nas que usas para procurar, filtrar e ordenar.
• Uma cache sem um prazo claro. Decide ao fim de quanto tempo se atualiza e deixa de fora os dados pessoais.

Checklist

• Trabalho numa cópia ou no ambiente de testes, não em produção
• A base de dados de testes tem dados falsos em quantidades realistas
• No teste, os serviços externos são falsos
• Tenho a lista das três páginas mais lentas, com motivo e correção
• Corrigi uma coisa de cada vez, com os tempos antes e depois
• Sei ao fim de quanto tempo se atualiza cada cache

Perguntas frequentes