Por qué las colas no solucionan la sobrecarga y qué hacer en su lugar
Lead
En el mundo del software, cuando un sistema se enfrenta a un pico de tráfico, la respuesta instintiva suele ser la misma: aumentar el tamaño de las colas, añadir un buffer o incorporar un sistema de mensajería como Kafka o RabbitMQ. Sin embargo, según el ingeniero de software y creador del framework Tina, pmbanugo, esta solución es un parche que solo retrasa el colapso. Las colas no solucionan la sobrecarga; simplemente transforman un fallo controlado en una catástrofe diferida. La clave está en la teoría de colas, la Ley de Little y la inevitable espiral de muerte por latencia. La alternativa, defiende el autor, es la descarga de carga (load shedding) y el backpressure, mecanismos que fuerzan al sistema a rechazar trabajo de forma inmediata cuando se alcanza la capacidad máxima.
Desarrollo
En su artículo «Why Queues Don’t Fix Overload (And What To Do Instead)», pmbanugo utiliza la analogía de una bañera: si el grifo vierte agua más rápido de lo que el desagüe puede evacuar, agrandar la bañera solo retrasa el desbordamiento. Lo mismo ocurre en los sistemas informáticos. Cuando la tasa de llegada (λ) supera la tasa de procesamiento, la cola crece indefinidamente hasta consumir toda la memoria, provocando que el sistema operativo mate el proceso o que el servicio quede inoperativo.
La Ley de Little (L = λW) demuestra matemáticamente este fenómeno. Con una tasa de llegada de 5.000 solicitudes por segundo y una capacidad de procesamiento de 1.000, el número de elementos en la cola (L) crece sin límite. Pero el problema no termina ahí: las solicitudes antiguas se vuelven obsoletas cuando los clientes agotan su tiempo de espera o refrescan la página, generando nuevas peticiones que se acumulan al final de la cola. El sistema gasta ciclos de CPU procesando solicitudes muertas, la tasa efectiva de procesamiento empeora, y la presión de memoria desencadena pausas de recolección de basura que ralentizan aún más el sistema. Es la espiral de muerte por latencia.
El autor argumenta que la única solución realista es descartar datos. «No puedes procesar datos más rápido de lo que tu hardware permite», afirma. La decisión de ingeniería es cómo y dónde descartar. La mayoría de los frameworks realizan una descarga implícita cuando la memoria se agota y el sistema operativo mata el proceso, perdiendo todas las solicitudes en curso. La alternativa es la descarga explícita mediante load shedding y backpressure.
Análisis
pmbanugo propone un enfoque radical: cuando el sistema está al límite, debe rechazar nuevas tareas de inmediato. «Debe mirar al remitente a los ojos y decir: “Estoy lleno. Vete”», escribe. Esta retroalimentación instantánea permite que el emisor tome decisiones de política: reintentar, mostrar un error o degradar la experiencia. No es un fallo del sistema, sino su defensa exitosa.
El autor lo ha implementado en su framework Tina, construido en Odin, que utiliza un modelo de actores con buzones estrictamente acotados y preasignados. Un buzón de Isolate (unidad de concurrencia) contiene 256 mensajes por defecto. Cuando se intenta enviar un mensaje a un buzón lleno, el sistema rechaza la operación en tiempo O(1) sin asignar memoria dinámica. El desarrollador debe manejar explícitamente el resultado .mailbox_full y decidir si descarta la solicitud o la reintenta. Para los casos en que se necesita fiabilidad, Tina ofrece un patrón .call que permite esperar una respuesta hasta un tiempo límite.
Perspectivas divergentes: en la industria, muchos equipos siguen prefiriendo colas grandes o sistemas de mensajería asíncrona para absorber picos, argumentando que la pérdida de datos es inaceptable. Sin embargo, pmbanugo sostiene que esa postura es ingenua: «Las colas solo son útiles cuando la tasa de trabajo entrante es ocasional y temporalmente superior a la tasa de finalización». No están diseñadas para cargas sostenidas. Su enfoque recuerda a los principios de sistemas reactivos y resilientes, donde el backpressure es un patrón central (como en Reactive Streams o Akka).
Conclusión
La lección es clara: para sistemas que deben operar bajo estrés, las colas sin límite son un bug. La solución no es almacenar más, sino rechazar antes. Herramientas como Tina demuestran que es posible construir sistemas con recursos acotados y retroalimentación explícita. Mientras tanto, la comunidad de ingeniería de software sigue debatiendo el equilibrio entre disponibilidad y consistencia. Lo que está claro es que, en la próxima crisis de tráfico, agrandar la bañera no salvará el sistema: habrá que cerrar el grifo.