Definición
Una cola de mensajes es una lista de tareas pendientes: un proceso las deposita y otro proceso, aparte, las va cogiendo y ejecutando.
Lo que introduce es una separación entre aceptar un trabajo y hacerlo. La aplicación web responde al usuario inmediatamente —«recibido»— y el trabajo lento ocurre después, sin que nadie espere delante de una pantalla en blanco.
Los cuatro problemas que resuelve:
Tareas lentas. Generar un PDF, enviar cien correos, procesar un fichero grande. Nadie debería esperar en el navegador a que eso termine.
Picos de carga. Si llegan mil peticiones de golpe, la cola las absorbe y se procesan al ritmo que el sistema aguante en vez de tumbarlo.
Servicios externos poco fiables. Si una API ajena está caída, el mensaje se queda en la cola y se reintenta, en lugar de perderse.
Desacoplar partes. Quien encola no necesita saber quién procesa ni cuántos procesadores hay.
Las reglas que no se pueden saltar
Los mensajes se entregan al menos una vez. Esto significa que un mensaje puede procesarse dos veces: el trabajador se cae después de terminar pero antes de confirmar, y la cola lo vuelve a repartir.
Consecuencia directa y no negociable: las tareas deben ser idempotentes. Ejecutarlas dos veces tiene que dar el mismo resultado que ejecutarlas una. Si tu tarea cobra a un cliente, ese requisito deja de ser teórico.
El orden no está garantizado salvo que la cola lo prometa explícitamente. No asumas que dos mensajes se procesarán en el orden en que se enviaron.
Los fallos hay que acotarlos. Un mensaje que falla siempre —datos corruptos, un error de programación— reintentaría infinitamente y bloquearía el resto. Por eso existe la cola de fallidos: tras N intentos, el mensaje se aparta para revisarlo a mano.
Ejemplo práctico
En un sistema de gestión, los candidatos naturales a ir a una cola son reconocibles: envío de correos, generación de documentos, sincronización con sistemas externos y avisos.
Lo que aprendí: el cambio más notable no es el rendimiento, es la experiencia. Un formulario que envía cinco correos y espera a que salgan tarda segundos y falla si el servidor de correo va lento. El mismo formulario encolando responde al instante y el correo sale cuando salga.
Y hay un beneficio menos obvio: los fallos dejan de ser del usuario. Si el envío falla, se reintenta solo; el usuario no ve un error por algo que no depende de él ni tiene que volver a rellenar nada.
El segundo aprendizaje, sobre por dónde empezar: no hace falta una infraestructura dedicada para empezar. Una tabla de tareas pendientes con estado y contador de intentos, más un proceso periódico que la vaya vaciando, cubre perfectamente los volúmenes de un sistema de empresa pequeña o mediana. Ver tarea programada.
La cola dedicada aporta cuando hay mucho volumen, varios consumidores o exigencias de latencia. Antes de eso, añade piezas que mantener.
Y una advertencia sobre la visibilidad: lo que va a una cola desaparece de la vista. Sin un panel que muestre cuántos mensajes hay pendientes, cuántos fallaron y cuánto tardan, una cola atascada pasa desapercibida durante días. Es el mismo fallo silencioso de las tareas programadas, multiplicado.
Errores comunes
- Tareas no idempotentes en una cola que reintenta.
- Reintentos infinitos sin cola de fallidos.
- Asumir el orden de procesamiento.
- No vigilar la cola. Ver observabilidad.
- Meter en el mensaje objetos enormes en vez de un identificador.
- Encolar lo que debía ser inmediato, y que el usuario no entienda por qué su acción «no ha hecho nada».
- Montar infraestructura pesada para diez tareas al día.
Cuándo usarlo
Cuando una operación tarda más de lo que alguien debería esperar, depende de un servicio externo o debe sobrevivir a un pico.
La pregunta que decide: ¿el usuario necesita el resultado ahora mismo para continuar? Si no lo necesita, va a la cola. Si lo necesita, no.
