De 1.2s para 180ms: como refatorar microsserviços para suportar 4x mais requisições
Quando a latência de uma API sobe nos horários de pico, o instinto comum é jogar mais infraestrutura no problema: mais réplicas, instâncias maiores, mais réplicas de banco. Isso funciona até não funcionar mais — e geralmente esconde o problema real em vez de resolvê-lo. Este é o passo a passo que uso para diagnosticar e corrigir isso na origem.
Primeiro, diagnosticar — não adivinhar
Antes de mexer em qualquer código, é preciso saber onde o tempo está sendo gasto. Adicionar cache ou mais réplicas sem esse diagnóstico é jogar dinheiro fora.
- Profiling da aplicação: identificar se o tempo está no processamento, em I/O de rede ou em espera de lock/mutex.
- Análise de queries: consultas N+1, falta de índices, e queries que fazem full scan em tabelas grandes são as causas mais comuns de latência que "aparece do nada" sob carga.
- Pool de conexões: sob concorrência alta, um pool de conexões de banco mal dimensionado gera fila invisível — a query em si é rápida, mas a requisição espera uma conexão livre.
As três frentes que mais impactam
- Reestruturar a camada de persistência: índices compostos para os padrões de acesso reais, eliminação de N+1 com batching, e separação de leituras pesadas de relatório do caminho crítico de escrita.
- Caching distribuído com Redis: cache-aside para dados lidos com frequência e escritos raramente, com invalidação explícita no write path — cache sem estratégia de invalidação clara vira fonte de bug, não de performance.
- Processamento assíncrono: tudo que não precisa de resposta síncrona (notificações, atualização de métricas, tarefas secundárias) sai do caminho crítico da requisição e vai para uma fila.
O resultado
Com essas três mudanças — sem trocar de infraestrutura — o tempo médio de resposta caiu de 1,2s para 180ms, e a mesma infraestrutura passou a suportar o quádruplo de requisições simultâneas. Nenhuma das mudanças, isoladamente, teria chegado nesse resultado: o ganho vem de atacar concorrência, I/O e trabalho desnecessário no caminho crítico ao mesmo tempo.
Checklist antes de otimizar
- Você tem dados de profiling reais, ou está otimizando por intuição?
- As queries lentas já foram identificadas com EXPLAIN, ou é achismo?
- O que pode sair do caminho síncrono sem quebrar a experiência do usuário?
- Existe estratégia de invalidação de cache antes de adicionar cache?
Se a sua API está degradando sob carga e o time já tentou "jogar mais servidor" sem resultado consistente, o problema provavelmente está em uma dessas três frentes — e um diagnóstico técnico direcionado custa muito menos do que continuar escalando infraestrutura para compensar um gargalo de código.