Contexto
Uma plataforma de live commerce usada em lives de vendas de uma grande marca de moda brasileira. Os eventos costumavam chegar a cerca de 6.000 usuários simultâneos; um passou de 12.000. O backend rodava no Google Cloud Run depois de uma migração recente da AWS para o GCP, e a plataforma nunca tinha sido testada com essa carga.
O que falhou
- O banco saturou primeiro, principalmente em CPU e memória, e a pressão se espalhou pelo resto da infraestrutura.
- A capacidade não crescia rápido o bastante. Milhares de pessoas entraram de uma vez e, entre cold starts e a configuração de autoscaling, as novas instâncias chegavam depois que a demanda já estava lá.
- A migração era recente, mas o problema só apareceu com esse nível de tráfego.
Resposta imediata
O evento estava ao vivo, então estabilidade vinha antes do diagnóstico. Os recursos foram aumentados emergencialmente para manter a plataforma no ar durante o evento. Isso ganhou tempo, não uma explicação.
Reproduzindo a falha
- Depois do evento, reproduzimos a carga em condições controladas com o Taurus.
- Os desenvolvedores simularam milhares de usuários simultâneos, aumentando a carga passo a passo.
- Métricas e logs em cada etapa mostravam quais limites eram atingidos primeiro.
Mudanças
Com o time de infraestrutura, ajustamos a infraestrutura e o autoscaling do Cloud Run, testamos de novo e repetimos. Cada rodada buscava o equilíbrio entre capacidade suficiente para absorver milhares de usuários chegando ao mesmo tempo e o custo de manter essa capacidade disponível.
Minha contribuição
Como Desenvolvedor Sênior, trabalhei com o time de infraestrutura em:
- Rodar os testes de carga com Taurus e ler os resultados junto com métricas e logs.
- Analisar onde estavam os limites e participar de cada rodada de ajustes de autoscaling e capacidade.
- Testar de novo depois de cada mudança.
Resultado
Depois dos ajustes, os testes de carga sustentaram cerca de 20.000 usuários simultâneos sem ultrapassar o orçamento de infraestrutura definido para esse cenário. É um resultado de teste de carga, não de um evento posterior em produção.
Lição de engenharia
Um pico é um problema diferente de crescimento. O autoscaling reage a uma demanda que já existe, então, quando milhares de pessoas chegam no mesmo minuto, os cold starts decidem se a capacidade aparece a tempo. Um teste de carga que sobe devagar passa em um sistema que falha numa live; ele precisa reproduzir a entrada simultânea. A partir daí, performance é um equilíbrio entre capacidade, velocidade de reação e o custo de mantê-la pronta.