RabbitMQ es útil cuando un controlador distribuye trabajos independientes entre workers de navegador, Android, integraciones o datos. Desacopla creación y ejecución y aporta backpressure, routing y confirmaciones. No sustituye a la base de datos que guarda el estado de negocio.
Una topología sencilla de producción
La API valida la petición, escribe el trabajo en base de datos y publica un mensaje pequeño con ID, tipo de tarea, referencia de cliente o cuenta, prioridad y versión de esquema. Un exchange durable lo enruta a colas por capacidad: Android, navegador o enriquecimiento.
Los workers consumen pocos mensajes, cargan el estado actual, reservan el recurso necesario y ejecutan. Solo confirman después de guardar el resultado durable. Este modelo amplía los principios de diseñar colas de trabajo para bots móviles.
Asume entrega al menos una vez
Un worker puede completar un efecto y caer antes del acknowledgement; RabbitMQ entregará de nuevo. Haz la operación idempotente: asigna una clave estable, comprueba el estado completado y usa restricciones de base de datos o idempotencia remota.
No confirmes al inicio ni crees bucles infinitos de requeue. Clasifica fallos como transitorios, permanentes o inciertos. Un resultado incierto necesita reconciliación antes de repetir una acción externa.
Reintentos y dead letters
Usa colas de reintento limitadas con retrasos crecientes mediante dead-letter routing o el mecanismo de mensajes retrasados si está aprobado en tu entorno. Guarda número de intento y categoría del último error. Tras el límite, envía el trabajo a dead-letter y márcalo para revisión.
Errores de autenticación, entrada inválida o restricciones de política no suelen ser reintentables. Timeouts, errores temporales o dispositivos no disponibles pueden serlo. Añade jitter para evitar que todos los workers golpeen a la vez un servicio recuperado.
Controla la concurrencia de recursos reales
Una cola larga no autoriza workers ilimitados. Ajusta prefetch según duración y memoria. Mantén una reserva activa por teléfono, perfil o cuenta cuando las acciones paralelas entren en conflicto. Los límites por servicio y cuenta deben aplicarse fuera de RabbitMQ.
Configura heartbeats, recuperación de conexión y publisher confirms. Las quorum queues encajan cuando disponibilidad y seguridad justifican su coste; elige según la configuración soportada actualmente y prueba fallos de nodos antes de producción.
Haz visible el sistema
Monitoriza mensajes listos y sin confirmar, edad del trabajo más antiguo, tasas de publicación y finalización, reintentos, dead letters, capacidad y latencia total. Propaga un ID de correlación. No pongas credenciales, tokens ni páginas completas en los mensajes.
Combina métricas del broker con los logs que necesitas para depurar bots. Una cola saludable todavía puede ocultar resultados de negocio incorrectos.
Errores comunes
- usar RabbitMQ como fuente de verdad
- meter archivos grandes o secretos en mensajes
- confirmar antes de guardar el resultado
- suponer ejecución exactamente una vez
- reencolar todos los errores para siempre
- mezclar workers incompatibles en una cola
- ignorar prefetch y reservas de recursos
- no usar publisher confirms ni revisar dead letters
- medir tamaño de cola pero no edad y resultados
Checklist práctico
- definir un esquema mínimo y versionado
- guardar estado de negocio en base de datos
- usar colas durables y mensajes persistentes cuando proceda
- activar publisher confirms y acknowledgements manuales
- hacer cada operación idempotente o reconciliable
- clasificar errores y limitar reintentos
- configurar dead-letter y repetición operativa
- ajustar prefetch, workers y reservas
- propagar IDs y logs estructurados seguros
- probar caídas de workers, broker y dependencias
Cuándo tiene sentido contratar a una persona técnica
Contrata a un especialista cuando los trabajos generan acciones pagadas o irreversibles, varios workers comparten dispositivos escasos, necesitas aislamiento por cliente o las colas deben sobrevivir a fallos. Lo difícil es definir estado, entrega, reconciliación y operación, no instalar RabbitMQ.
Conclusión
RabbitMQ es un buen coordinador cuando los mensajes describen el trabajo en vez de contener todo el sistema. Mantén workers idempotentes, reintentos finitos y fallos visibles. Si necesitas una arquitectura que se recupere con seguridad, revisa mis servicios técnicos o contacta conmigo.