Nosso bot do Slack lidou com 200 mensagens por dia durante três meses sem dificuldades. Então, um blogueiro de tecnologia mencionou-o em uma newsletter, e passamos de 200 para 12.000 mensagens em 48 horas.
Tudo quebrou. Não dramaticamente — o servidor não pegou fogo nem nada. Ele apenas… desacelerou. E desacelerou mais. E então começou a derrubar mensagens. E depois ficou completamente silencioso enquanto 12.000 pessoas se perguntavam por que o bot de IA que acabaram de conhecer não estava respondendo.
Aqui está o que aconteceu, o que fizemos e como escalamos de “divertido projeto paralelo” para “algo de que as pessoas realmente dependem” em uma semana.
As Primeiras 6 Horas: Negação e Pânico
A newsletter chegou às caixas de entrada às 9 AM em uma terça-feira. Às 10 AM, nossa fila de mensagens tinha um backlog de 400 mensagens. Ao meio-dia, a fila estava em 2.000 e o tempo de resposta era de 45 segundos (normalmente abaixo de 3 segundos).
Minha primeira reação: “Huh, isso é muita mensagem.” 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 exigia uma chamada de API, e estávamos atingindo os limites de taxa severamente. Nosso plano de API do nível gratuito permitia 60 solicitações por minuto. Precisávamos de 200+ por minuto.
Solução rápida: atualizar o plano de API. Conseguimos nosso limite de taxa para 500 solicitações por minuto em 30 minutos ao mudar para um plano pago. A fila começou a ser descartada. Crise parcialmente evitada.
Mas então a segunda onda chegou.
Horas 6-24: Tudo o Quebrado
Aumentar o throughput da API revelou todos os outros gargalos que não havíamos notado em baixo volume.
Conexões de banco de dados esgotadas. Cada mensagem acionava uma busca no banco de dados para o contexto do usuário. A 200 mensagens/dia, sem problemas. A 12.000, nosso pool de conexões estava esgotado. Usuários receberam erros de “serviço indisponível”.
Solução: aumentamos o tamanho do pool de conexões, adicionamos agrupamento de conexões com PgBouncer e implementamos réplicas de leitura para as buscas de contexto.
Vazamento de memória no manipulador de mensagens. Uma variável que armazenava o contexto da conversa estava crescendo sem ser limpa. Em baixo volume, cresceu lentamente e foi limpa com reinicializações ocasionais. Em alto volume, consumiu toda a memória disponível em cerca de 4 horas.
Solução: adicionamos limpeza adequada após cada mensagem ser processada. Esse erro estava lá desde o primeiro dia — ele simplesmente nunca importou até que importou.
Processamento de thread única. As mensagens estavam sendo processadas sequencialmente. Uma por vez. A 200 mensagens/dia, isso estava bem. A 12.000, significava que cada mensagem esperava atrás de cada outra mensagem.
Solução: implementamos processamento concorrente com uma fila de tarefas adequada. As mensagens são distribuídas entre vários trabalhadores. Isso sozinha reduziu o tempo médio de resposta de 45 segundos para menos de 5.
O Momento “Oh, Precisamos de Infraestrutura Real”
À 24ª hora, percebi que nossa arquitetura de “funciona em um VPS de $10/mês” não seria capaz de lidar com o crescimento sustentável. Precisávamos:
Um balanceador de carga adequado. Não porque precisássemos de vários servidores ainda, mas porque precisávamos de verificações de saúde, reinicializações automáticas e a capacidade de implantar atualizações sem tempo de inatividade.
Uma fila de mensagens. Fila de tarefas respaldada pelo Redis que desacopla o recebimento de mensagens do processamento de mensagens. Se o modelo de IA estiver lento, as mensagens esperam na fila em vez de expirar. Se um trabalhador travar, a mensagem é reprocessada em vez de perdida.
Monitoramento que realmente alerta. Tínhamos registro. Não tínhamos alertas. A diferença importa quando as coisas quebram às 2 AM e ninguém está olhando os logs.
Escalonamento horizontal. A capacidade de adicionar mais trabalhadores quando a carga aumenta. Nossa arquitetura agora se autoescalar: se a profundidade da fila exceder um limiar, novos trabalhadores são ativados automaticamente.
O Que Enviamos em uma Semana
Dia 1-2: Atualização de limite de taxa de emergência, 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, escalonamento horizontal.
Dia 7: Finalmente dormi.
O custo total da infraestrutura passou de $10/mês para cerca de $120/mês. Mas passamos de suportar 200 mensagens/dia para lidar confortavelmente com 50.000. E a arquitetura pode escalar ainda mais apenas adicionando trabalhadores.
A Lista de Verificação de Escalonamento que Eu Gostaria de Ter Tido
Se seu bot de IA está ganhando tração e você quer estar preparado antes que o pico chegue:
Configure o monitoramento com alertas agora. Tempo de resposta, taxa de erro, profundidade da fila, uso de memória. Limiares de alerta em 2x os valores normais. Você quer saber sobre problemas antes que os usuários te digam.
Implemente uma fila de mensagens. Mesmo em baixo volume. Isso desacopla o recebimento do processamento, permite reprocessamentos e torna o escalonamento horizontal trivial mais tarde.
Perfilar o uso de recursos por mensagem. Quantas consultas ao banco de dados por mensagem? Quanta memória? Quantas chamadas de API? Multiplique isso pela sua meta de crescimento e veja onde estarão os gargalos.
Teste com 10x sua carga atual. Use uma ferramenta de teste de carga para simular 10x o volume de mensagens por uma hora. Observe o que quebra. Corrija antes que quebre em produção.
Tenha um plano de escalonamento documentado. “Se o tráfego dobrar, faça essas três coisas.” Ter o plano escrito significa que você pode executá-lo às 2 da manhã quando está meio dormindo, em vez de tentar arquitetar soluções sob pressão.
O Que Aprendi Sobre IA em Grande Escala
O modelo de IA não é geralmente o gargalo — tudo ao seu redor é. Consultas ao 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, as coisas chatas importam mais do que as coisas de IA.
Além disso: limites de taxa são a restrição de escalonamento mais subestimada em aplicações de IA. Sua arquitetura brilhante não importa se a API do modelo permite apenas 60 solicitações por minuto. Verifique seus limites antes de lançar e tenha um plano para quando você os exceder.
A explosão viral foi estressante, mas, no fim, positiva. Isso nos forçou a construir a infraestrutura que deveríamos ter construído desde o início. E agora estamos prontos para o próximo pico — sempre que ele venha.
🕒 Published: