Técnico
Cómo separar trabajos lentos con RabbitMQ 4.3.6
RabbitMQ permite sacar tareas lentas del flujo principal. Guía para colas, acuses, permisos, backup y prueba de salida en pymes argentinas hoy.
El cierre falla cuando la factura espera al PDF y al correo en la misma cola. En muchas pymes, una tarea lenta toma el turno de todas las demás y soporte solo ve un botón girando. RabbitMQ 4.3.6 permite separar trabajos, acuses y reintentos con permisos por vhost; esta guía explica qué cola usar, qué dato guardar y cómo probar la salida.
Dónde aparece la cola que tapa al resto
El síntoma operativo es simple: ventas confirma una operación, el sistema genera un comprobante, adjunta un PDF, manda correo, avisa a depósito y actualiza un tablero. Si todo corre dentro de la misma solicitud web, un proveedor de SMTP lento o un PDF pesado bloquea tareas que ya podrían quedar registradas. El antagonista tiene nombre conocido: el cron único que hace todo junto a las 18:00. RabbitMQ publicó la versión 4.3.6 el 14 de septiembre de 2026. Entre sus cambios aparece un límite nuevo, channel_tx_message_max, que por defecto acota en 10.000 la cantidad de publicaciones que un canal puede acumular dentro de una transacción AMQP 0-9-1. Esa cifra importa porque obliga a mirar cuántos mensajes produce una tanda y qué pasa cuando el consumidor queda atrasado. En la encuesta 2026 de Stack Overflow, 74% de quienes construyen software interno con IA dijeron que armaron scripts o automatizaciones y 66% trabajó en herramientas internas de equipo. Ese dato conecta con Cuyo: el problema ya no es tener una aplicación, sino separar trabajos repetibles para que una cola atrasada no tape caja, depósito o soporte.
Cómo funciona por dentro
El flujo mínimo tiene seis pasos. Primero, la aplicación guarda la operación principal en PostgreSQL 17: factura, estado, usuario, fecha y auditoría. Segundo, publica un mensaje en RabbitMQ con un identificador, tipo de tarea y ruta del dato; RabbitMQ recibe el mensaje y lo enruta desde un exchange hacia una cola. Tercero, un consumidor toma la tarea, genera el PDF o manda el correo, y responde con un acuse. Cuarto, la aplicación marca estado final o error en PostgreSQL. Quinto, el plugin de management muestra colas, consumidores, tasa de mensajes y memoria para cada vhost. Sexto, el backup exporta definiciones y copia datos persistentes; una prueba restaura un mensaje real y verifica qué se procese una sola vez. Las colas no reemplazan la auditoría de negocio. RabbitMQ guarda mensajes y estado técnico de entrega; PostgreSQL conserva el registro que una persona necesita leer después. Si un correo falla tres veces, el sistema debe mostrar factura, mensaje, intento, error y responsable. El permiso también vive en dos lugares. RabbitMQ define usuarios por vhost para publicar, consumir o administrar colas. La aplicación define quién puede reenviar una factura, cancelar una tarea o cerrar un caso. Un error en cualquiera de los dos lados crea trabajos invisibles. ## Qué se instala o configura primero Para una pyme, el arranque prudente es un broker RabbitMQ 4.3.6, PostgreSQL 17 para estados, un worker por tipo de tarea, métricas de management y copia nocturna. Un nodo único para tareas internas de bajo riesgo puede costar entre USD 30 y USD 50 por mes. Si el flujo exige continuidad ante caída de nodo, tres servidores pequeños suben el rango a USD 90-150 mensuales; a 1.540 pesos por dólar vendedor, son 138.600 a 231.000 pesos, sin horas de puesta en marcha. El primer entregable verificable es una tarea lenta aislada: por ejemplo, generar PDF de factura fuera del request principal. El botón debe responder, la cola debe recibir un mensaje, el worker debe procesarlo y el tablero debe mostrar éxito o error. Una implementación básica lleva una o dos semanas si la aplicación ya guarda estados claros. UMSA suele entrar cuando el equipo ya sabe qué tarea duele, aunque todavía no puede medirla. En una clínica privada de Godoy Cruz, el patrón sirve para autorizaciones, turnos y comprobantes: la atención guarda el dato, el worker hace el trabajo pesado y soporte mira una cola con dueño.
Dónde se rompe y cómo probarlo
El primer riesgo aparece en mensajes sin acuse. La señal es una tarea que figura enviada y nunca cambia de estado. La prueba apaga el worker en mitad del proceso, lo reinicia y verifica que el mensaje vuelva a la cola o quede marcado para revisión. El segundo riesgo está en consumidores demasiado rápidos para una base lenta. La señal. CPU baja, memoria alta y backlog creciente. La prueba limita prefetch, ejecuta 1.000 mensajes de muestra y mide cuántos quedan pendientes por minuto. El tercer riesgo vive en reintentos infinitos. La señal es una cola que repite el mismo error y ocupa todo el tablero. La prueba fuerza un correo inválido, cuenta tres intentos y manda el mensaje a una cola de revisión con error legible. El cuarto riesgo aparece en backup. La señal es una restauración que levanta el broker sin usuarios, colas o permisos. La prueba exporta definiciones, restaura en otro host, publica un mensaje y confirma que el consumidor correcto lo toma. Una cola bien puesta deja una evidencia concreta: quién publicó, quién procesó, qué falló y qué dato quedó guardado.
