Arquitectura de bots escalable

Q: ¿Cuándo dejar de usar un bot stateless?

En cuanto necesitas recordar contexto entre mensajes, gestionar suscripciones o emparejar respuestas de soporte. Stateless aguanta hasta ~50 usuarios concurrentes en un flujo simple. A partir de ahí, perdés mensajes en reinicios, no podés escalar horizontal y no tenés trazabilidad. Pasá a stateful con PostgreSQL + Redis para colas.

Q: ¿Qué cola elegir: Redis, RabbitMQ o SQS?

Redis (con BullMQ) si ya usás Redis y querés algo simple, rápido y con UI. RabbitMQ si necesitás routing complejo, exchanges fanout/topic y consumers en varios lenguajes. SQS si vivís en AWS y querés cero operación con dead-letter queue gratis. Para un bot que recibe 10–500 msg/s, Redis + BullMQ cubre el 90% de casos.

Q: ¿Cómo manejar idempotencia en webhooks?

Cada plataforma envía un ID único (update_id en Telegram, message ID en Discord, id en WhatsApp). Guardalo en Redis con TTL de 24 h al recibir el webhook; si ya existe, descartá. Esto previene duplicados cuando la plataforma reintenta porque tu 200 OK llegó tarde.

Q: ¿Cuáles son los rate limits típicos?

Telegram: 30 mensajes/segundo global, 1/seg por chat individual, 20/min por grupo. Discord: 50 requests/seg por bot token, con buckets por endpoint. WhatsApp Cloud API: 80 msg/seg por número (escala con calidad). Si los superás, te frenan o te suspenden. Implementá leaky bucket o token bucket por canal.

Q: ¿Cómo escalar horizontal sin duplicar mensajes?

Los webhooks llegan a un único endpoint (Cloudflare → balanceador → N réplicas). Cada réplica solo encola; los workers consumen de la cola con ack manual. Si un worker muere, otro retoma el mensaje. Para polling (long-polling de Telegram), corré una sola instancia o usá leader election (Redis SET NX) para evitar duplicados.

Un bot que escala no es "un script más grande": es eventos → cola → workers → persistencia → integraciones, con límites de plataforma y observabilidad desde el día uno. Discord, Telegram y WhatsApp imponen rate limits distintos, esperan acuse de recibo en milisegundos y reintentan agresivamente si tu webhook falla. Este recurso es la arquitectura mínima que usamos en bots de producción: qué cambia entre un MVP y una versión que aguanta 500 msg/s sin perder ninguno.

1. El diagnóstico: por qué los bots caen en producción

El 80% de los bots que mueren en producción tienen el mismo perfil: un solo proceso Node/Python con todo en memoria, sin cola, sin idempotencia, respondiendo al webhook con la lógica de negocio síncrona. Funciona en pruebas y revienta el día que un grupo grande envía 50 mensajes en 3 segundos. Telegram reintenta, WhatsApp marca tu número como problemático, Discord te frena.

El otro 20% cae por multi-tenant mal hecho: un bot que sirve a 30 servidores de Discord guarda el estado en variables globales, mezcla configuraciones y un cliente acaba viendo datos de otro. La arquitectura escalable no es opcional cuando vendés el bot como servicio.

2. Capas mínimas de un bot production-ready

Ingesta: webhooks HTTPS detrás de balanceador (Cloudflare → Vercel/Fly/Railway). Respuesta 200 OK en <3 s siempre. Verificación de firma (Telegram secret_token, Discord X-Signature-Ed25519).
Idempotencia: guardar update_id/message_id en Redis con TTL 24 h antes de procesar. Si ya existe, descartar—la plataforma reintenta y duplicaría operaciones (cargos, mensajes, tickets).
Cola: Redis + BullMQ, RabbitMQ o SQS. El webhook solo encola; nunca ejecuta lógica de negocio. Esto desacopla picos y permite reintentos exponenciales con backoff.
Workers: N procesos consumiendo la cola con ack manual. Si un worker muere, otro retoma. Escalan horizontal sin coordinación. Concurrency configurable por tipo de job.
Estado: PostgreSQL para datos durables (usuarios, suscripciones, tickets, auditoría). Redis para cache, contadores y rate limiting. Nunca guardar estado en memoria del proceso.
Rate limiting saliente: token bucket por canal y por chat. Telegram: 30 msg/s global, 1/s por chat. Discord: respetar headers X-RateLimit-Remaining. WhatsApp: cuotas por número con escalado por calidad.
Observabilidad: logs estructurados (Pino/Winston) con trace_id por mensaje. Métricas Prometheus o Datadog (latencia p95, tasa de error, longitud de cola). Alertas en cola > X mensajes o error rate > Y%.
Dead-letter queue: mensajes que fallan N veces van a DLQ con el payload original. Inspección manual antes de reintentar o descartar. Sin DLQ se pierden datos en silencio.

3. Multi-tenant: un bot, muchos clientes

Si vendés el bot como servicio (un servidor Discord por cliente, una cuenta WhatsApp por empresa), tenant_id tiene que estar en cada tabla, cada job de cola y cada llamada a APIs externas. Patrones útiles:

Una configuración por tenant (mensajes, integraciones, idiomas) cacheada en Redis, invalidada en cambios.
Credenciales de APIs externas (CRM, OpenAI) por tenant, cifradas en reposo (KMS, Vault).
Rate limits y cuotas por tenant: un cliente abusivo no debe ahogar a los demás.
Métricas y logs etiquetados con tenant_id para diagnóstico aislado.
Plantillas de WhatsApp Business aprobadas por tenant (Meta exige aprobación por número).

4. MVP bot vs Production bot

MVP bot (semanas 1–2)

Un proceso Node/Python, sin cola
Webhook → handler síncrono
SQLite o Postgres simple
Logs a stdout, sin métricas
Sin idempotencia formal
Deploy en Railway/Render, un solo entorno
OK hasta ~50 usuarios concurrentes

Production bot

Webhook detrás de balanceador, N réplicas
Redis + BullMQ (o SQS), DLQ activa
Postgres con migraciones versionadas
Logs estructurados + Prometheus/Datadog
Idempotencia por message_id en Redis
Rate limit propio respetando el de la plataforma
Multi-tenant, secretos cifrados, backups
Aguanta 100–500 msg/s sin perder ninguno

5. Preguntas frecuentes

¿Cuándo dejar de usar un bot stateless?

En cuanto necesitás recordar contexto entre mensajes, gestionar suscripciones o trazar tickets. Stateless aguanta ~50 usuarios concurrentes; a partir de ahí perdés mensajes en reinicios y no podés escalar horizontal. Pasá a stateful con PostgreSQL + Redis para colas.

¿Qué cola elegir: Redis, RabbitMQ o SQS?

Redis + BullMQ si querés simple y rápido con UI. RabbitMQ si necesitás routing complejo, exchanges fanout/topic. SQS si vivís en AWS y querés cero operación con DLQ gratis. Para 10–500 msg/s, Redis cubre el 90% de casos.

¿Cómo manejar idempotencia en webhooks?

Cada plataforma envía un ID único (update_id en Telegram, message ID en Discord). Guardalo en Redis con TTL 24 h al recibir; si ya existe, descartá. Previene duplicados cuando la plataforma reintenta porque tu 200 OK llegó tarde.

¿Cuáles son los rate limits típicos?

Telegram: 30 msg/s global, 1/s por chat individual, 20/min por grupo. Discord: 50 req/s por bot token, con buckets por endpoint. WhatsApp Cloud API: 80 msg/s por número, escala con calidad. Si los superás, te frenan o te suspenden.

¿Cómo escalar horizontal sin duplicar mensajes?

Webhooks a un endpoint → balanceador → N réplicas. Cada réplica solo encola; workers consumen con ack manual. Para long-polling de Telegram, una sola instancia o leader election con Redis SET NX.

¿Necesitas implementación de bots a escala?

Diseñamos y desplegamos bots de Discord, Telegram y WhatsApp con colas, idempotencia, multi-tenant y observabilidad. Auditamos también bots existentes que pierden mensajes o se quedan colgados.

Servicio de bots Pedir presupuesto

Recursos relacionados

Guía: bots de Discord y Telegram — elección de canal, errores típicos al contratar.
Automatizar atención al cliente sin romper el CRM — el bot como capa de soporte.
Backend SaaS multi-tenant — patrones de aislamiento si vendes el bot como servicio.
Automatizar procesos en la empresa — dónde encaja un bot en operaciones internas.

Última actualización: junio de 2026 · Escrito por el estudio RoviDev.