Nosso bot Slack gerenciou 200 mensagens por dia durante três meses sem problemas. Então, um blogueiro de tecnologia mencionou isso em uma newsletter, e passamos de 200 para 12.000 mensagens em 48 horas.
Tudo parou de funcionar. Não de maneira espetacular — o servidor não pegou fogo nem nada. Ele simplesmente… desacelerou. E continuou desacelerando. Depois começou a perder mensagens. E então, ficou completamente silencioso enquanto 12.000 pessoas se perguntavam por que o bot de IA que acabaram de ouvir falar não estava respondendo.
Aqui está o que aconteceu, o que fizemos e como passamos de “projeto secundário divertido” para “algo do qual as pessoas realmente dependem” em uma semana.
As 6 primeiras horas: negação e pânico
A newsletter chegou às caixas de entrada às 9h00 de uma terça-feira. Às 10h00, nossa fila de mensagens tinha um atraso de 400 mensagens. Ao meio-dia, a fila atingia 2.000 e o tempo de resposta era de 45 segundos (normalmente menos de 3 segundos).
Minha primeira reação: “Hmm, isso é um monte de mensagens.” Minha segunda reação, 20 minutos depois: “Oh não.”
O gargalo não era a CPU ou a memória — era a API do modelo de IA. Cada mensagem requeria uma chamada de API, e estávamos rapidamente atingindo os limites de taxa. Nosso plano API gratuito permitia 60 requisições por minuto. Precisávamos de mais de 200 por minuto.
Solução rápida: atualizar o plano API. Aumentamos nosso limite para 500 requisições por minuto em 30 minutos ao passar para um plano pago. A fila começou a esvaziar. Crise parcialmente evitada.
Mas então, a segunda onda chegou.
Horas 6-24: tudo o resto falha
Aumentar a taxa da API revelou todos os outros gargalos que não havíamos notado em baixo volume.
Conexões ao banco de dados saturadas. Cada mensagem acionava uma busca no banco de dados para o contexto do usuário. A 200 mensagens/dia, sem problema. A 12.000, nosso pool de conexões estava esgotado. Os usuários recebiam erros de “serviço indisponível”.
Correção: aumento do tamanho do pool de conexões, adição de otimização de conexões com PgBouncer, e implementação de réplicas de leitura para as buscas de contexto.
Vazamento de memória no gerenciador de mensagens. Uma variável que armazenava o contexto da conversa crescia sem ser limpa. Em baixo volume, crescia lentamente e era purgada por reinicializações ocasionais. Em alto volume, consumia toda a memória disponível em cerca de 4 horas.
Correção: adição de uma limpeza apropriada após o processamento de cada mensagem. Este bug estava presente desde o primeiro dia — nunca havia importado até agora.
Processamento mono-thread. As mensagens eram processadas sequencialmente. Uma de cada vez. A 200 mensagens/dia, isso funcionava. A 12.000, isso significava que cada mensagem aguardava atrás de cada outra mensagem.
Correção: implementação de processamento concorrente com uma fila de tarefas apropriada. As mensagens são distribuídas entre vários trabalhadores. Isso reduziu o tempo de resposta médio de 45 segundos para menos de 5.
O momento “Oh, precisamos de uma verdadeira infraestrutura”
Após 24 horas, percebi que nossa arquitetura “funciona em um VPS de $10/mês” não conseguiria lidar com um crescimento sustentado. Precisávamos de:
Um verdadeiro balanceador de carga. Não porque precisássemos de vários servidores ainda, mas porque precisávamos de verificações de estado, reinicializações automáticas e a capacidade de implementar atualizações sem tempo de inatividade.
Uma fila de mensagens. Fila de tarefas suportada pelo Redis, que desacopla a recepção das mensagens do processamento das mensagens. Se o modelo de IA estiver lento, as mensagens aguardam na fila em vez de morrer nos tempos de espera. Se um trabalhador falhar, a mensagem é reutilizada em vez de ser perdida.
Monitoramento que realmente alerta. Tínhamos logs. Não tínhamos alertas. A diferença é significativa quando as coisas falham às 2 da manhã e ninguém está monitorando os logs.
Escalabilidade horizontal. A capacidade de adicionar mais trabalhadores quando a carga aumenta. Nossa arquitetura se redimensiona automaticamente: se a profundidade da fila ultrapassar um limite, novos trabalhadores são configurados automaticamente.
“`html
O que realizamos em uma semana
Dia 1-2: atualização de emergência do limite de taxa, correção do pool de conexões, correção de vazamento de memória.
Dia 3-4: implementação da fila de mensagens, processamento concorrente.
Dia 5-6: balanceador de carga, monitoramento com alertas, escalabilidade horizontal.
Dia 7: finalmente dormindo.
O custo total da infraestrutura passou de $10/mês para cerca de $120/mês. Mas passamos de 200 mensagens/dia para gerenciar confortavelmente 50.000. E a arquitetura ainda pode se adaptar simplesmente adicionando mais trabalhadores.
A lista de verificação de escalabilidade que eu gostaria de ter
Se o seu bot IA está crescendo e você quer estar pronto antes que o pico chegue:
Configure o monitoramento com alertas agora. Tempo de resposta, taxa de erros, profundidade da fila, uso de memória. Limites de alerta em 2x os valores normais. Você quer ser informado sobre problemas antes que os usuários relatem.
Implemente uma fila de mensagens. Mesmo em baixo volume. Isso desacopla a recepção do processamento, permite reenvios e torna a escalabilidade horizontal trivial mais tarde.
Analise seu uso de recursos por mensagem. Quantas requisições de banco de dados por mensagem? Quanto de memória? Quantas chamadas de API? Multiplique esses números pelo seu objetivo de crescimento e veja onde estão os gargalos.
Teste a 10 vezes sua carga atual. Use uma ferramenta de teste de carga para simular um volume de mensagens multiplicado por 10 durante uma hora. Veja o que falha. Corrija antes que falhe em produção.
Tenha um plano de escalabilidade documentado. “Se o tráfego dobrar, faça essas três coisas.” Ter o plano por escrito significa que você pode executá-lo às 2 da manhã quando estiver metade adormecido, em vez de tentar pensar em soluções sob pressão.
O que aprendi sobre IA em grande escala
O modelo IA geralmente não é o gargalo — tudo que o cerca é. Requisições de banco de dados, gerenciamento de contexto, formatação de saída, roteamento de mensagens — toda a infraestrutura “chata” que você ignora ao construir um protótipo. Em grande escala, os elementos chatos são mais importantes do que os elementos de IA.
Além disso: os limites de taxa são a restrição de escalabilidade mais subestimada em aplicações de IA. Sua arquitetura brilhante não importa se a API do modelo permite apenas 60 requisições por minuto. Verifique seus limites antes de lançar e tenha um plano para quando você os ultrapassar.
O pico viral foi estressante, mas finalmente positivo. Isso nos forçou a construir a infraestrutura que deveríamos ter implementado desde o início. E agora estamos prontos para o próximo pico — quando ele chegar.
“`
🕒 Published: