Seu sistema aguenta dobrar de clientes
Como saber se o sistema da sua empresa suporta crescer, quais gargalos aparecem primeiro e o que medir antes de investir em infraestrutura.
Resposta rápida
A maioria dos sistemas não falha por falta de servidor: falha por consulta mal feita ao banco de dados, que fica exponencialmente mais lenta conforme os dados crescem. Antes de contratar infraestrutura maior, vale medir onde o tempo está sendo gasto, porque trocar de servidor costuma comprar alguns meses pelo mesmo dinheiro que resolveria o gargalo de vez. O sinal de alerta não é a lentidão em si, é a lentidão que piora com o volume.
Neste artigo
A empresa vai dobrar a base de clientes este ano. Alguém pergunta se o sistema aguenta. A resposta honesta costuma ser: ninguém sabe.
E a reação mais comum — contratar um servidor maior “por segurança” — é também a mais cara por unidade de problema resolvido.
Lentidão constante e lentidão que piora
Essa distinção decide tudo.
Lentidão constante. O sistema sempre levou quatro segundos para abrir aquela tela, desde o primeiro dia. Costuma ser infraestrutura subdimensionada ou código ineficiente, e mais servidor de fato ajuda.
Lentidão que piora com o volume. A tela abria em meio segundo com mil registros e leva doze com cem mil. Esse é o padrão perigoso, e quase sempre significa consulta ao banco sem índice adequado.
A diferença importa porque no segundo caso o servidor maior é dinheiro jogado fora: uma consulta que percorre a tabela inteira continua percorrendo, só que mais rápido. Quando o volume dobra de novo, o problema volta — e agora com custo mensal maior.
Os gargalos na ordem em que aparecem
1. Banco de dados
É o primeiro e o mais comum, de longe.
Consulta sem índice cresce de forma desproporcional ao volume. Com mil registros ninguém nota; com um milhão, trava. Outro clássico é a consulta dentro de laço: a tela lista cem itens e faz uma consulta por item, somando cem viagens ao banco onde uma bastaria.
A boa notícia é que esse tipo de problema costuma estar concentrado em poucas consultas, e corrigir essas poucas resolve a maior parte do caso.
2. Processamento síncrono
O usuário clica e espera o sistema gerar o PDF, enviar o e-mail, chamar a API do parceiro. Com pouca gente simultânea, passa. Com o dobro de usuários, as requisições se acumulam.
A correção é tirar do caminho do usuário o que não precisa de resposta imediata: a tarefa vai para uma fila e o usuário segue trabalhando.
3. Arquivos no mesmo servidor
Fotos, anexos e documentos ocupando o disco da aplicação. Funciona até o disco encher ou até o backup ficar tão grande que ninguém mais faz.
4. Infraestrutura
É o último da fila, não o primeiro — ao contrário do que a reação instintiva sugere.
O que medir antes de gastar
Três medições, e nenhuma exige trocar nada:
- Quais telas estão lentas e quanto tempo levam. Não impressão: número.
- Quais consultas ao banco consomem mais tempo. Todo banco tem como registrar isso.
- Como os recursos do servidor se comportam no pico. Processador, memória e disco no horário de maior uso.
Com esses três, a decisão deixa de ser palpite. Normalmente aparece que poucas consultas respondem pela maior parte do tempo perdido — e corrigi-las custa muito menos que qualquer upgrade.
Como testar se aguenta dobrar
Não é preciso adivinhar. Dá para simular carga: ferramentas de teste reproduzem o dobro de usuários simultâneos num ambiente de teste e mostram onde quebra primeiro.
Isso é mais barato que descobrir em produção, no mês em que a campanha de vendas der certo.
Quando o problema não é performance
Às vezes o sistema aguenta tecnicamente e ainda assim não suporta o crescimento, por outros motivos:
- Não tem permissão por pessoa, e com equipe maior isso vira risco.
- Depende de uma pessoa que faz um passo manual todo dia.
- Não tem como auditar quem fez o quê, e com mais gente isso passa a importar.
Esses não se resolvem com índice nem com servidor. São limites de arquitetura, e a decisão sobre o que fazer está em refatorar ou reescrever.
Por onde começar
Se o sistema já está lento, comece medindo — não comprando.
Um diagnóstico de poucos dias costuma apontar onde está a maior parte do tempo perdido, e a correção das consultas específicas resolve a maioria dos casos por uma fração do custo de infraestrutura maior.
Se quiser essa avaliação, me chame.
Perguntas frequentes
Como sei se o problema é o servidor ou o sistema?
Pelo padrão da lentidão. Se o sistema é lento sempre, igualmente, costuma ser infraestrutura ou código mal otimizado. Se ele era rápido e foi ficando lento conforme os dados cresceram, o problema quase sempre é consulta ao banco sem índice adequado, e mais servidor só adia.
Trocar para um servidor maior resolve?
Compra tempo, não resolve causa. Uma consulta que varre a tabela inteira continua varrendo, só que num computador mais rápido. Quando o volume dobra de novo, o problema volta — e agora com custo mensal maior. Vale medir antes de pagar.
O que medir antes de investir?
Três coisas: quais telas estão lentas e quanto tempo levam, quais consultas ao banco consomem mais tempo, e como o uso de recursos do servidor se comporta no horário de pico. Sem isso, qualquer investimento é palpite caro.
Quanto custa resolver um gargalo desses?
Costuma ser barato em relação ao impacto, porque o problema normalmente está concentrado em poucas consultas. Um diagnóstico de alguns dias costuma apontar onde está a maior parte do tempo perdido, e a correção dessas consultas específicas resolve a maior parte dos casos.
Quem escreve
Thainan Prado
Desenvolvedor full stack sênior com mais de 8 anos de experiência, responsável por sistemas em produção para empresas como OXXO, Ambev e Shell Select. Desenvolve sistemas sob medida, automações e integrações para PMEs e empresas médias de todo o Brasil.