Colas de trabajo fiables: qué ocurre cuando un mensaje se procesa dos veces
Diseña consumidores, confirmaciones y recuperación para que los trabajos en segundo plano toleren interrupciones y entregas repetidas.

Antes de entrar en detalle
- Confirmar la recepción no equivale a completar la operación de negocio.
- Diseña el consumidor para reconocer trabajos repetidos y controlar efectos externos.
- Prueba interrupciones en puntos concretos y vigila la antigüedad del trabajo pendiente.
Mover una tarea a una cola permite responder antes al usuario y distribuir el trabajo entre procesos. También introduce un intervalo en el que pueden fallar conexiones, reiniciarse consumidores o repetirse entregas. Un sistema que funciona con un único mensaje en una demostración puede duplicar efectos al recuperarse de una interrupción. La fiabilidad depende de definir cuándo se considera terminado el trabajo y qué sucede si el mismo evento vuelve a llegar después de haber producido algún cambio.
Distingue publicación, entrega y resultado
Que el productor haya enviado un mensaje no demuestra que el consumidor lo haya completado. RabbitMQ distingue confirmaciones de publicación y confirmaciones del consumidor: cubren etapas diferentes y no conocen automáticamente el resultado de la otra. La aplicación debe definir qué significa éxito para su tarea. Generar un archivo, guardar un cambio y avisar a una persona son efectos distintos. Si el flujo necesita confirmar un resultado de negocio, debe conservar ese estado y ofrecer una forma de consultarlo.
Decide cuándo confirmar el trabajo
Una confirmación demasiado temprana puede perder la tarea si el proceso cae antes de terminar. Una confirmación posterior permite recuperar trabajo pendiente, pero puede provocar una nueva entrega cuando el efecto ya ocurrió y se perdió la respuesta. No existe una posición mágica que elimine todos los fallos entre sistemas independientes. El diseño debe considerar ese intervalo y permitir reconocer operaciones realizadas, especialmente cuando el consumidor modifica una base de datos o llama a otro servicio con consecuencias visibles.
Usa una identidad estable del evento
Asigna a cada evento una identidad que se conserve en sus entregas. El consumidor puede registrar qué eventos aplicó y utilizar una restricción de unicidad para impedir que dos procesos los acepten simultáneamente. Cuando el efecto está en la misma base de datos, guardar el cambio y la marca de procesamiento en una transacción ayuda a mantener coherencia. No basta con consultar primero si existe una marca y escribirla después sin coordinación: dos consumidores podrían superar la comprobación a la vez.
La retención de esas marcas requiere una decisión explícita. Si se eliminan antes de que una entrega antigua pueda reaparecer, el sistema volverá a aceptar el evento. Relaciona la conservación con la política de mensajes, las recuperaciones y los posibles reprocesados históricos. Para efectos externos, comprueba si el servicio receptor ofrece su propio mecanismo de identificación o conciliación. La marca local no revierte un aviso o una operación que otro sistema ya ejecutó.
Separa errores recuperables y mensajes problemáticos
Un fallo temporal de conexión merece un tratamiento diferente de un mensaje cuyo formato nunca será válido. Define límites y una vía de revisión para eventos que no puedan procesarse. Una cola de errores resulta útil si tiene responsable, contexto y procedimiento de recuperación; abandonarla convierte un fallo visible en trabajo olvidado. Antes de reintroducir mensajes, corrige la causa y decide si sus datos siguen siendo vigentes. El reprocesado debe respetar las mismas protecciones frente a duplicados.
- Conserva identificador, tipo y versión del evento.
- Confirma el trabajo después del punto de éxito definido para la tarea.
- Coordina el registro de procesamiento con los cambios locales cuando sea posible.
- Define tratamiento para errores permanentes y revisión del trabajo apartado.
- Prueba entregas simultáneas y reinicios antes y después de cada efecto relevante.
Vigila el tiempo de espera además del tamaño
Una cola pequeña puede contener un trabajo antiguo bloqueado, mientras una cola grande puede vaciarse rápidamente. Observa antigüedad del mensaje más viejo, ritmo de entrada y salida, duración del procesamiento y errores por tipo. Limita la concurrencia según la capacidad de las dependencias: añadir consumidores sin criterio puede saturar la base de datos y empeorar el rendimiento. Mantén una vista del estado de negocio para que soporte pueda distinguir pendiente, en curso, completado y requiere revisión.
Ensaya los fallos en los límites del flujo
En un entorno controlado, interrumpe el consumidor antes de guardar, después de guardar y antes de confirmar. Envía el mismo evento dos veces y comprueba tanto la respuesta técnica como el efecto final. Simula también un mensaje incompatible y una dependencia temporalmente inaccesible. Estos ensayos muestran si la recuperación produce duplicados, pérdidas o estados ambiguos. Una cola fiable se reconoce cuando el equipo puede explicar qué ocurrió con una tarea y recuperarla sin ejecutar a ciegas todo el trabajo anterior.
Fuentes y lecturas recomendadas
Referencias para ampliar el contexto y consultar la documentación original. Las guías enlazadas pueden actualizarse después de la fecha de este artículo.
Comparte esta lectura
Enviar por email