O app estava ótimo com cem usuários. Com dez mil, as telas demoram, o login falha e começam as avaliações negativas. Esse é um problema bom de ter, porque significa que o produto cresceu, mas só é bom se você souber resolver. A boa notícia é que a maioria dos casos se corrige com poucas medidas, aplicadas na ordem certa.
Primeiro passo: meça antes de mexer
O erro mais comum é sair trocando coisas sem saber onde está o problema. Antes de qualquer ajuste, descubra:
- Quais telas e ações estão lentas, e em quais horários.
- O tempo de resposta do servidor para cada pedido do app.
- O uso de processador, memória e conexões do servidor e do banco de dados.
- Os erros que aparecem e com que frequência.
- A origem dos acessos: muitos usuários simultâneos, um pico por causa de uma campanha ou uma ação específica pesada.
Ferramentas de monitoramento e de relatório de erros mostram esses dados. Se ainda não tem nada configurado, comece por aí. O texto sobre métricas de app ajuda a escolher o que acompanhar.
Onde costumam estar os gargalos
Banco de dados
Na maioria dos apps, é o primeiro lugar a sofrer. Problemas frequentes:
- Falta de índices: o banco precisa varrer a tabela inteira para encontrar um registro. Um índice, como o índice de um livro, acelera isso.
- Consultas pesadas ou repetidas: a mesma informação pedida mil vezes. Um caso clássico é buscar uma lista e, depois, fazer uma nova consulta para cada item dela, o que multiplica os pedidos sem necessidade.
- Trazer dados demais: pedir todas as colunas e todos os registros quando a tela mostra só dez.
Se você é iniciante em bancos de dados, veja banco de dados e SQL para iniciantes.
Servidor e processamento
Tarefas pesadas (gerar relatórios, enviar e-mails, processar imagens) rodando no mesmo momento do pedido do usuário fazem todo mundo esperar.
Serviços de terceiros
Mapas, pagamentos e envios de mensagens têm limites de uso. Quando o app cresce, você pode bater nesses limites e receber recusas.
O próprio app no celular
Listas enormes carregadas de uma vez, imagens pesadas e muitas chamadas à internet deixam o app lento mesmo com servidor perfeito.
As medidas, em ordem de custo-benefício
- Otimize o banco de dados: crie índices nos campos mais pesquisados, reescreva consultas lentas e use paginação (mostrar 20 itens por vez, em vez de todos).
- Use cache: guarde em memória ou em um serviço próprio as respostas que mudam pouco e são muito pedidas, para evitar refazer o trabalho a cada acesso.
- Otimize imagens e arquivos: comprima, entregue no tamanho certo para cada tela e use uma rede de distribuição de conteúdo (CDN), que serve os arquivos de um ponto mais perto do usuário. O guia de como deixar o site mais rápido traz ideias que servem ao app também, como reduzir o peso das páginas e dos arquivos enviados.
- Mova o trabalho pesado para segundo plano: use filas e processos em background. O usuário recebe a resposta na hora e o restante é feito depois.
- Limite abusos: aplique limites de requisições por usuário para evitar que um acesso desordenado derrube os outros.
- Aumente a capacidade: só depois dos passos anteriores. Pode ser um servidor mais potente (escala vertical) ou mais servidores trabalhando juntos, divididos por um balanceador de carga (escala horizontal).
- Escale o banco de dados: réplicas para leitura, planos maiores ou serviços gerenciados, quando as otimizações já foram feitas.
Se o seu backend é um serviço pronto
Quem usa serviços como Firebase ou Supabase tem boa parte da infraestrutura gerenciada, mas ainda precisa cuidar das mesmas questões: consultas eficientes, índices, regras e limites do plano. Confira os limites de uso, de conexões e de cobrança do seu plano, e configure alertas de gasto para não receber uma surpresa. O comparativo Firebase ou Supabase mostra como cada um funciona.
Em plataformas no-code, os limites costumam estar no plano: número de registros, de usuários e de operações por mês. Se você chegou ao teto, a solução pode ser mudar de plano ou migrar partes do projeto.
Teste de carga: descubra antes dos usuários
Antes de campanhas, lançamentos ou datas de pico, simule muitos usuários simultâneos em um ambiente de teste. Ferramentas conhecidas de teste de carga, como k6 e JMeter, ajudam. Observe em que ponto o tempo de resposta degrada e qual componente falha primeiro. Corrija e teste de novo. Nunca faça testes de carga no ambiente real sem aviso, nem contra serviços de terceiros sem permissão.
Prepare-se para falhar com elegância
Mesmo com tudo certo, algo vai falhar um dia. Reduza o impacto:
- Mensagens claras no app quando o servidor não responde, com opção de tentar de novo.
- Funcionamento parcial: se uma função não essencial cai (por exemplo, recomendações), o resto continua.
- Lançamento gradual de novas versões, com possibilidade de voltar atrás. Veja a rotina em manutenção de app depois do lançamento.
- Backups testados do banco de dados.
- Alertas para a equipe quando erros ou lentidão passarem de um limite.
Cuidado com a complexidade desnecessária
Dividir o sistema em muitas partes (a chamada arquitetura de microsserviços), usar tecnologias da moda e planejar para milhões de usuários antes de ter mil costuma ser caro e atrapalhar. Resolva o gargalo atual com a medida mais simples que funcione e evolua conforme os números pedirem.
Para começar hoje: instale monitoramento, descubra a tela mais lenta, olhe as consultas dela no banco e corrija o que for óbvio. Muitas vezes esse trabalho pequeno devolve a velocidade e dá tempo para planejar o próximo passo com calma.