Por qué tu app de Telegram falla al llegar a las 50 cuentas
Funciona con 5 cuentas, se cae con 50. Los 6 muros técnicos que rompen a casi todos los SaaS de Telegram cuando intentan escalar.
Casi todos los proyectos serios de Telegram pasan por la misma curva: arrancan con 5 cuentas, todo va bien, empiezan a vender, suman cuentas y de repente, alrededor de las 50 cuentas en paralelo, la app se rompe. No es una cifra mágica — es el punto donde varias deficiencias arquitectónicas convergen.
Este post desglosa los 6 muros técnicos que rompen a la mayoría de los SaaS de Telegram. Si estás construyendo uno, léelo antes de prometer escala a tus clientes.
Muro 1: Sesiones sin lock distribuido
Cada cuenta de Telegram tiene un solo auth_key válido a la vez. Si dos procesos abren la misma sesión simultáneamente, Telegram emite un AUTH_KEY_DUPLICATED y mata la conexión (explicado aquí).
Con 5 cuentas y un solo worker, esto no pasa nunca. Con 50 cuentas y 4 workers, pasa todo el tiempo: dos workers toman tareas para la misma cuenta y abren clientes en paralelo.
La solución obligatoria: lock distribuido por cuenta (Redis con TTL). Antes de abrir un cliente MTProto, el worker pide el lock. Si ya está tomado, espera o pasa al siguiente.
Los SaaS que no lo tienen, queman cuentas. Punto.
Muro 2: Pool de conexiones sin reciclaje
Abrir una conexión MTProto cuesta entre 800ms y 2s (handshake + auth + negotiation de layer). Si abres y cierras una conexión por cada mensaje, el handshake se vuelve el cuello de botella.
La arquitectura correcta:
- Mantén las conexiones abiertas y reusables dentro de cada worker
- Cierra conexiones que llevan más de X minutos inactivas
- Recicla la conexión cuando detectas error de red persistente
Sin esto, con 50 cuentas y mensajes cada minuto, tu app pasa más tiempo haciendo handshake que enviando mensajes.
Muro 3: FloodWait sin backoff inteligente
FloodWait es el error que dice "espera N segundos antes de volver a intentar". Es el mecanismo principal de control de Telegram.
Errores comunes en este punto:
- Reintentar inmediatamente: garantiza ban en 24h
- Ignorar el
secondsque devuelve Telegram: peor, multiplica el ban - Mismo backoff para todas las cuentas: si una cuenta tiene FloodWait, las demás siguen volando — bien — pero si todas entran en FloodWait sincronizado, tu throughput cae a cero
La respuesta correcta: backoff exponencial por cuenta, jitter entre 0-30% para evitar sincronización, máximo 3 reintentos antes de pausar la cuenta automáticamente.
Muro 4: Queue sin priorización
Con 5 cuentas todo cabe en una cola FIFO. Con 50 cuentas, vas a tener:
- Mensajes urgentes (1:1 con cliente VIP)
- Mensajes de campaña (broadcast)
- Stories programadas
- Sync de grupos
- Warming de cuentas nuevas
Si todo va a la misma cola, los mensajes urgentes esperan detrás de un batch de 10,000 broadcasts. Tu cliente VIP recibe respuesta en 3 horas.
La arquitectura correcta son colas separadas con prioridad (BullMQ lo hace nativamente):
cola:urgent— prioridad 1cola:broadcast— prioridad 2cola:warming— prioridad 3cola:sync— prioridad 4
Cada cola con su concurrencia y rate limit. Esto se conoce como workers especializados y es el patrón que Vega Punk usa en producción.
Muro 5: Cifrado de sesiones en plain text
Las sesiones MTProto (StringSession) son literalmente las llaves del reino. Con una sesión válida, cualquiera opera como esa cuenta.
A 5 cuentas, las guardas en una variable de entorno o JSON local y nadie nota. A 50 cuentas, eso es un riesgo de seguridad inaceptable: un acceso no autorizado a tu DB compromete TODAS las cuentas de TODOS tus clientes.
Lo mínimo razonable:
- AES-256-GCM con clave maestra en variable de entorno
- Rotación de clave maestra cada 90 días
- Logs de acceso a sesiones (audit trail)
- Nunca log de la sesión completa, ni siquiera en debug
Más detalle en cómo cifrar sesiones GramJS bien.
Muro 6: Sin observabilidad por cuenta
A 5 cuentas, mirar logs en terminal funciona. A 50 cuentas, no tienes ni idea de qué pasa. ¿Cuál cuenta tiene FloodWait? ¿Cuál se desconectó? ¿Cuál tiene reintentos infinitos? Vuelo a ciegas.
Mínimo observable:
- Métricas por cuenta: mensajes/hora, FloodWait actuales, último envío exitoso
- Health check corriendo cada N minutos por cuenta
- Alertas cuando una cuenta entra en estado degradado (FLOOD_WAIT > 24h, AUTH_KEY_DUPLICATED, etc.)
- Dashboard agregado con el estado de todo el pool
Sin esto, tu equipo dedica más tiempo a "encontrar el problema" que a resolverlo.
La métrica clave: mensajes por cuenta por día
Aquí está la matemática que tienes que tener clarísima:
- Una cuenta de Telegram bien calentada soporta unos 70 mensajes/día sostenibles.
- Si quieres enviar 7,000 mensajes/día, necesitas 100 cuentas activas mínimo.
- Si quieres enviar 70,000 mensajes/día, necesitas 1,000 cuentas activas.
Cada cuenta es un proceso completo: lock, conexión, warming, observabilidad, rotación de proxy. Multiplicar por 1,000 no es trivial. Es la diferencia entre un side-project y una infraestructura de marketing real.
¿Cómo sé si mi app va a romper?
Si tu sistema actual cumple todas estas condiciones, vas bien:
- Tienes lock distribuido en Redis con TTL configurado
- Tus workers son procesos independientes con colas separadas
- FloodWait pausa solo la cuenta afectada, no el sistema
- Sesiones están cifradas con AES-256
- Tienes métricas por cuenta visibles en un dashboard
- Has probado con al menos 100 cuentas en paralelo en staging
Si fallas en una sola de las anteriores, vas a chocar con el muro antes de las 50 cuentas. No es opinión: lo hemos visto romper en 8 proyectos distintos.
La verdad incómoda
Construir esto bien es 6-12 meses de un equipo senior. La mayoría de SaaS de Telegram que ves en el mercado tienen 1-3 de los 6 muros resueltos, no los 6. Por eso prometen 100 cuentas y revientan a las 30.
Cuando evalúes una herramienta de Telegram, pregúntales:
- ¿Cómo manejan AUTH_KEY_DUPLICATED?
- ¿Tienen lock distribuido por cuenta?
- ¿FloodWait pausa una cuenta o todo el sistema?
- ¿Las sesiones están cifradas en la DB?
- ¿Puedo ver métricas por cuenta en su dashboard?
Si dudan o evitan responder, ya sabes en qué muro están.
Conclusión
Los 6 muros son: lock distribuido, pool de conexiones, FloodWait inteligente, queue con prioridad, cifrado de sesiones, observabilidad por cuenta. Resolverlos todos es lo que separa un SaaS de Telegram que funciona en demo de uno que funciona a 500 cuentas en producción.
Vega Punk los tiene resueltos. No porque sea más inteligente, sino porque rompimos contra cada uno de ellos durante un año. Si quieres saltarte ese año, bienvenido.