Construindo uma Infraestrutura de Bot Que Não Pegue Fogo

“`html

Naquela vez em que um bot “simples” derreteu um banco de dados

Alguns anos atrás, eu implementei o que achava ser uma pequena funcionalidade em um bot em produção. Ele apenas precisava preencher algumas metadados de usuário que faltavam. Nada demais. Dez minutos depois, o banco de dados principal estava chorando, alertas estavam explodindo meu telefone e o bot estava em um loop de reinicialização.

O bug não estava na lógica do negócio. O bug estava na infraestrutura que eu não me dei ao trabalho de projetar.

Eu tinha lançado um bot que falava com o banco de dados diretamente, de forma inline, em cada mensagem. Sem fila. Sem limites de taxa. Sem pressão de retorno. Quando uma API externa desacelerava, os trabalhadores se acumulavam, as contagens de conexão disparavam e o DB levou um soco na cara.

Esse foi o dia em que parei de pensar “ah, é só um bot” e comecei a tratar bots como qualquer outro sistema em produção que pode absolutamente arruinar sua infraestrutura se você não tomar cuidado.

Se você está construindo bots dos quais usuários reais dependem, você precisa de infraestrutura. Não de uma infraestrutura gigante como uma catedral kubernetes. Apenas as peças certas, conectadas corretamente, para que o bot não caia no segundo em que se torna popular ou um endpoint de API se comporta mal.

A arquitetura mínima viável de bot que realmente funciona

Vamos falar sobre as peças principais. Quando eu digo “infraestrutura de bot”, quero dizer as coisas que permitem que seu bot:

• Sobreviva a picos de tráfego
• Gerencie APIs externas lentas ou instáveis
• Recupere-se de bugs sem necessidade de supervisão manual
• Informe o que está quebrado antes que os usuários o façam

Você não precisa de vinte serviços para isso. Você precisa de um punhado de serviços entediantes, usados de forma consistente.

1. Ponto de entrada sem estado

O ponto de entrada do seu bot (webhook/endereço HTTP/poller) deve ser o mais sem estado e rápido possível.

• Receber evento (Slack, Discord, WhatsApp, o que for).
• Validá-lo (assinatura, timestamp).
• Colocá-lo em uma fila.
• ACK a plataforma rapidamente.

Em um bot do Slack, mantivemos o tempo de resposta HTTP abaixo de 150ms consistentemente fazendo quase nada no manipulador de solicitações. Todo o trabalho caro foi para os trabalhadores. Isso sozinha eliminou 90% dos problemas de timeout aleatórios que as pessoas culpam por “o Slack estar estranho”.

2. Uma fila real, não “apenas um goroutine”

Eu gosto do RabbitMQ e Redis (via algo como bullmq ou rq) para a maioria dos bots. O AWS SQS também é bom. Escolha um e se comprometa.

Sua fila é onde você:

• Desacopla a ingestão do processamento
• Controla a concorrência (número máximo de trabalhos em andamento)
• Gerencia tentativas e cartas mortas

Para um bot que lancei em 2023 que processava webhooks do GitHub, começamos sem fila “para manter simples”. Em 3k eventos/minuto durante uma grande queda no CI, os servidores de aplicativos caíram porque cada solicitação tentou fazer tudo. Mudamos para SQS + pool de trabalhadores, limitado a 50 trabalhos simultâneos, e a mesma carga mal tocou a CPU.

3. Processos de trabalhador que você pode escalar e matar

Um trabalhador deve fazer uma coisa: puxar mensagens da fila e processá-las. Só isso. Sem servir HTTP. Sem misturar funções.

Um trabalhador razoável:

• Tem um limite de concorrência claro (por exemplo, 20 trabalhos por pod)
• Implementa timeouts em chamadas externas (por exemplo, 3–5 segundos)
• Usa lógica de circuit breaker para recuar em falhas persistentes
• Emite métricas por tipo de trabalho

Quando a CPU dispara, você adiciona mais trabalhadores. Quando algo está quebrado, você pode reduzir os trabalhadores a zero sem tocar no ponto de entrada de ingestão.

4. Armazenamento que corresponde ao uso real do bot

Bots geralmente precisam de três tipos de armazenamento:

• Configuração/estado (preferências do usuário, tokens) → Postgres, DynamoDB, o que você realmente sabe operar.
• Sessões (contexto da conversa) → Redis com TTLs ou seu armazenamento vetorial se for pesado em LLM.
• Logs/eventos (para análise e depuração) → ClickHouse, BigQuery ou até mesmo S3 + parquet.

O erro é jogar tudo em um único banco de dados. É assim que você acaba com uma caixa-misteriosa lenta e cara que ninguém quer tocar.

Falhas que você encontrará (e como não entrar em pânico)

Todo bot que sobrevive mais de um mês em produção enfrenta as mesmas 5–6 classes de falha. Você pode se preparar para elas agora ou depurá-las às 3 da manhã enquanto olha para um painel do Grafana com as mãos tremendo.

1. APIs externas ficam lentas ou fora do ar

Se seu bot chama Slack, Discord, OpenAI ou algum CRM de terceiros: assuma que eles vão absolutamente se comportar mal.

• Use timeouts para cada solicitação.
• Implemente tentativas com jitter e retrocesso exponencial.
• Use um disjuntor (circuit breaker) para parar de martelar um serviço quebrado.

“`

Em um bot do Telegram que chama a API da OpenAI, limitamos as chamadas simultâneas da OpenAI a **40 por região**, e fazemos **3 tentativas com backoff** (250ms, 1s, 4s). Durante uma interrupção regional em **2024**, as solicitações desaceleraram para **20+ segundos**, mas o restante do sistema permaneceu ativo porque não estávamos acumulando milhares de trabalhadores bloqueados.

2. Tempestades de mensagens e tentativas da plataforma

Slack, WhatsApp e outros tentarão novamente os webhooks se seu endpoint estiver lento ou retornar **5xx**. Se seu bot estiver lento e seu manipulador não for idempotente, você terá processamento duplicado. Ou triplo.

Resolva isso:

• Tornando os manipuladores idempotentes usando uma chave de deduplicação (ID de solicitação, ID de mensagem).
• Armazenando “marcadores de processados” em um armazenamento rápido (um conjunto Redis com TTL está bom).
• Registrando duplicatas para que você possa realmente vê-las acontecer.

3. Tarefas descontroladas

Uma tarefa que nunca termina é pior do que uma tarefa que falha rapidamente. Ela consome concorrência e silenciosamente estrangula a fila.

Use:

• Timeouts rigorosos por tarefa (por exemplo, **30 segundos** para tarefas normais, **5 minutos** para pesadas).
• Ganchos de cancelamento onde seu cliente HTTP ou cliente LLM respeita o cancelamento de contexto.
• Máximo de tentativas (por exemplo, **5**) antes de enviar para a fila de mensagens mortas.

Observabilidade: como você sabe que o bot está morrendo antes dos usuários

Se você não tem visibilidade, você não tem infraestrutura. Você tem apenas uma intuição.

No mínimo, você precisa de três coisas:

1. Métricas

Prometheus + Grafana ainda é minha escolha padrão. Acompanhe:

• Profundidade da fila por tipo de tarefa
• Latência de processamento de tarefas (p50/p95)
• Taxa de erros por integração (Slack, OpenAI, CRM, etc.)
• Taxa de tarefas enviadas para a fila de mensagens mortas

Um alerta simples como “profundidade da fila > **10.000** por **5 minutos**” me salvou mais vezes do que qualquer detecção de anomalia complicada.

2. Registros

Use registros estruturados. Não me importa se é Loki, ELK ou Datadog. Apenas:

• Inclua IDs de correlação (por usuário, por conversa, por tarefa).
• Registre as respostas das APIs externas quando falharem (pelo menos status + erro).
• Registre tentativas e decisões de backoff.

3. Rastros (opcional, mas muito bom)

OpenTelemetry realmente vale a pena para bots que tocam múltiplos serviços. Rastrear uma única mensagem de usuário de webhook → fila → trabalhador → API externa → resposta torna a depuração **10x mais rápida**.

O que eu construiria se estivesse começando um bot hoje

Se você me disser “Estou começando um projeto de bot neste fim de semana, ajude-me a não me arrepender da minha vida em três meses”, aqui está o que eu sugeriria:

• Ponto de entrada HTTP: **FastAPI / Express / Go net/http** atrás de um balanceador de carga básico.
• Fila: **Redis + bullmq** (Node) ou rq/dramatiq (Python). Ou SQS se você usar **AWS**.
• Trabalhadores: implantação/processo separado, escalonamento horizontal com base na profundidade da fila.
• Armazenamento: **Postgres** para configuração, **Redis** para sessões, **S3** para logs ou transcrições de longo prazo.
• Métricas: **Prometheus + Grafana**, alertas conectados à profundidade da fila e à taxa de erro.
• Segredos: **Vault** ou o gerenciador de segredos da sua nuvem. Nunca insira tokens no código. Jamais.

Nada disso é sofisticado. Esse é o ponto. Bots não falham porque faltam uma nova tecnologia brilhante. Eles falham porque os fundamentos são ignorados.

Se você tratar seu bot como um brinquedo, seus usuários perceberão. Se você tratá-lo como qualquer outro serviço de produção, poderá dormir a noite inteira ao invés de depurar tentativas do Slack na cama.

Perguntas Frequentes

Quantos trabalhadores eu realmente preciso para meu bot?

Comece pequeno. Considere o tempo médio da tarefa e seu pico esperado de mensagens por segundo. Se as tarefas levam **200ms** e você espera **20 mensagens/segundo**, isso significa **4 tarefas simultâneas**. Multiplique por **2–3x** para segurança, então talvez **10 trabalhadores**. Depois, monitore a CPU, a latência e a profundidade da fila, e ajuste com base em dados reais.

Eu realmente preciso de uma fila para um bot com baixo tráfego?

Menos de **5 mensagens por minuto** e sem chamadas externas pesadas? Você pode conseguir sem uma. No momento em que você adiciona operações caras (chamadas LLM, gravações no DB, APIs de terceiros), adicione uma fila. É mais barato do que depurar tempos limites estranhos e processamento duplicado mais tarde.

O Kubernetes é exagerado para a infraestrutura do bot?

Para a maioria dos bots, sim, pelo menos no começo. Algumas contêineres Docker no **ECS, Fly.io** ou máquinas virtuais comuns com **systemd** estão bons. O Kubernetes começa a fazer sentido quando você tem vários bots, serviços compartilhados ou isolamento multi-inquilino rigoroso. Até lá, mantenha tudo simples e sem graça.

🕒 Published: April 5, 2026