Nuestra bot de Slack manejó 200 mensajes por día durante tres meses sin sudar. Luego, un blogger tecnológico lo mencionó en un boletín, y pasamos de 200 a 12,000 mensajes en 48 horas.
Todo falló. No dramáticamente — el servidor no se incendió ni nada por el estilo. Simplemente… se ralentizó. Y se ralentizó más. Luego comenzó a perder mensajes. Y después se quedó completamente en silencio mientras 12,000 personas se preguntaban por qué el bot de IA del que acababan de oír no respondía.
Esto es lo que sucedió, lo que hicimos y cómo escalamos de “divertido proyecto secundario” a “cosa de la que la gente realmente depende” en una semana.
Las Primeras 6 Horas: Negación y Pánico
El boletín llegó a los correos a las 9 AM de un martes. Para las 10 AM, nuestra cola de mensajes tenía un retraso de 400 mensajes. Para el mediodía, la cola estaba en 2,000 y el tiempo de respuesta era de 45 segundos (normalmente menos de 3 segundos).
Mi primera reacción: “Eh, eso es un montón de mensajes.” Mi segunda reacción, 20 minutos después: “Oh no.”
El cuello de botella no era la CPU o la memoria — era la API del modelo de IA. Cada mensaje requería una llamada a la API, y estábamos superando los límites de tasa fuertemente. Nuestro plan de API gratuito permitía 60 solicitudes por minuto. Necesitábamos más de 200 por minuto.
Solución rápida: actualizar el plan de API. Logramos que nuestro límite de tasa llegara a 500 solicitudes por minuto en 30 minutos al cambiar a un plan de pago. La cola comenzó a drenarse. Crisis parcialmente evitada.
Pero luego llegó la segunda ola.
Horas 6-24: Todo Lo Demás Se Rompe
Aumentar el rendimiento de la API reveló todos los otros cuellos de botella que no habíamos notado a bajo volumen.
Conexiones de base de datos al máximo. Cada mensaje activaba una búsqueda en la base de datos para el contexto del usuario. A 200 mensajes/día, no había problema. A 12,000, nuestro grupo de conexiones se agotó. Los usuarios recibieron errores de “servicio no disponible”.
Solución: aumentar el tamaño del grupo de conexiones, agregar agrupamiento de conexiones con PgBouncer e implementar réplicas de lectura para las búsquedas de contexto.
Fuga de memoria en el manejador de mensajes. Una variable que almacenaba el contexto de la conversación crecía sin ser limpiada. A bajo volumen, crecía lentamente y se limpiaba con reinicios ocasionales. A alto volumen, consumía toda la memoria disponible en aproximadamente 4 horas.
Solución: agregar una limpieza apropiada después de que se procese cada mensaje. Este error había estado presente desde el día uno — simplemente nunca importó hasta que sí lo hizo.
Procesamiento de un solo hilo. Los mensajes se estaban procesando secuencialmente. Uno a la vez. A 200 mensajes/día, esto estaba bien. A 12,000, significaba que cada mensaje esperaba detrás de cada otro mensaje.
Solución: implementar procesamiento concurrente con una cola de trabajos adecuada. Los mensajes se distribuyen entre varios trabajadores. Esto por sí solo redujo el tiempo de respuesta promedio de 45 segundos a menos de 5.
El Momento de “Oh, Necesitamos Infraestructura Real”
Para la hora 24, me di cuenta de que nuestra arquitectura de “funciona en un VPS de $10/mes” no iba a manejar un crecimiento sostenido. Necesitábamos:
Un equilibrador de carga adecuado. No porque necesitáramos múltiples servidores todavía, sino porque necesitábamos chequeos de salud, reinicios automáticos y la capacidad de implementar actualizaciones sin tiempo de inactividad.
Una cola de mensajes. Cola de trabajos respaldada por Redis que desacopla la recepción de mensajes del procesamiento de mensajes. Si el modelo de IA es lento, los mensajes esperan en la cola en lugar de agotar el tiempo. Si un trabajador falla, el mensaje se reintenta en lugar de perderse.
Monitoreo que realmente alerte. Teníamos registros. No teníamos alertas. La diferencia importa cuando las cosas fallan a las 2 AM y nadie está mirando los registros.
Escalado horizontal. La capacidad de agregar más trabajadores cuando aumenta la carga. Nuestra arquitectura ahora se escala automáticamente: si la profundidad de la cola excede un umbral, nuevos trabajadores se inician automáticamente.
Lo Que Entregamos en Una Semana
Día 1-2: Actualización de límite de tasa de emergencia, solución al grupo de conexiones, solución a la fuga de memoria.
Día 3-4: Implementación de la cola de mensajes, procesamiento concurrente.
Día 5-6: Equilibrador de carga, monitoreo con alertas, escalado horizontal.
Día 7: Finalmente dormí.
El costo total de infraestructura pasó de $10/mes a alrededor de $120/mes. Pero pasamos de soportar 200 mensajes/día a manejar cómodamente 50,000. Y la arquitectura puede escalar aún más simplemente agregando trabajadores.
La Lista de Verificación de Escalado Que Ojalá Hubiera Tenido
Si tu bot de IA está ganando tracción y quieres estar listo antes de que llegue el pico:
Configura el monitoreo con alertas ahora. Tiempo de respuesta, tasa de errores, profundidad de la cola, uso de memoria. Umbrales de alerta en 2x los valores normales. Quieres saber sobre problemas antes de que los usuarios te lo digan.
Implementa una cola de mensajes. Incluso a bajo volumen. Desacopla la recepción del procesamiento, permite reintentos y hace que el escalado horizontal sea trivial más adelante.
Perfiliza el uso de recursos por mensaje. ¿Cuántas consultas a la base de datos por mensaje? ¿Cuánta memoria? ¿Cuántas llamadas a la API? Multiplica estos por tu objetivo de crecimiento y ve dónde estarán los cuellos de botella.
Prueba con 10x tu carga actual. Usa una herramienta de pruebas de carga para simular 10x el volumen de mensajes durante una hora. Observa qué se rompe. Repara eso antes de que se rompa en producción.
Ten un plan de escalado documentado. “Si el tráfico se duplica, haz estas tres cosas.” Tener el plan escrito significa que puedes ejecutarlo a las 2 AM cuando estás medio dormido en lugar de intentar arquitectar soluciones bajo presión.
Lo Que Aprendí Sobre IA a Escala
El modelo de IA no suele ser el cuello de botella — todo lo que lo rodea lo es. Consultas a la base de datos, gestión de contexto, formato de salida, enrutamiento de mensajes — toda la infraestructura “aburrida” que omites al construir un prototipo. A gran escala, lo aburrido importa más que lo relacionado con la IA.
Además: los límites de tasa son la restricción de escalado más subestimada en aplicaciones de IA. Tu arquitectura brillante no importa si la API del modelo solo permite 60 solicitudes por minuto. Verifica tus límites antes de lanzar y ten un plan para cuando los superes.
El pico viral fue estresante pero en última instancia positivo. Nos obligó a construir la infraestructura que deberíamos haber construido desde el principio. Y ahora estamos listos para el próximo pico — cuandoquiera que llegue.
🕒 Published: