Reliable Messaging

Este mapa conecta publicación durable, tratamiento de repeticiones y recuperación de mensajes que no pueden seguir normalmente. El objetivo es identificar qué frontera protege cada mecanismo y quién conserva la obligación cuando el proceso falla.

Recorrido por preguntas

Documento	Función y pregunta
transactional-outbox	Canónico: ¿cómo conservar coherencia entre el cambio local y la intención de publicar?
inbox-pattern	Canónico: ¿cómo coordinar identidad de procesamiento y efecto local?
idempotent-consumer	Perspectiva de Idempotency: ¿cómo tolerar mensajes repetidos sin multiplicar el efecto relevante?
retry-topologies	Perspectiva de Retry: ¿dónde espera un mensaje que falló temporalmente, cuándo vuelve y quién controla ese ciclo?
dead-letter-queue	Canónico: ¿cómo apartar un caso que necesita inspección y recuperación?

Antes de elegir mecanismos, precisar delivery-guarantees y at-least-once. Después distinguir idempotency, propiedad del efecto, de deduplication, mecanismo de reconocimiento. Un inbox puede implementar deduplicación; una operación naturalmente idempotente puede no necesitarlo.

Un flujo frecuente, no obligatorio

Order Service: local commit of order + outbox
  -> relay
  -> message broker
  -> Inventory Consumer: local commit of inbox + reservation
 
temporary processing failure eligible for retry
  -> delayed redelivery with the same logical intention
  -> Inventory Consumer
 
processing cannot continue under its policy
  -> DLQ
  -> inspection and explicit recovery

dual-write-problem motiva transactional-outbox para esa publicación. El relay puede repetir mensajes; idempotent-consumer y inbox-pattern son opciones para proteger el procesamiento local. La semántica del dominio puede ofrecer otra solución y no todos los flujos necesitan ambos registros.

Fronteras y responsabilidad

Frontera	Qué puede quedar demostrado	Qué sigue pendiente
Commit de Order DB	Pedido e intención de publicación confirmados juntos.	El relay debe conseguir la aceptación acordada del broker.
Confirmación del broker	El transporte aceptó el mensaje según su contrato.	Cada consumidor debe resolver su efecto.
Commit de Inventory DB con inbox	Identidad y efecto local coordinados, durante su retención.	APIs externas y otras publicaciones necesitan su propio contrato.
Traslado a DLQ	El caso fue separado, si la transferencia fue durable.	Un responsable debe inspeccionarlo y resolver la intención.

exactly-once-semantics ayuda a evaluar estas afirmaciones. Combinar outbox e inbox no extiende automáticamente la garantía a todos los efectos ni obliga a ejecutar el código una sola vez.

La pregunta por significado continúa en interoperability: entregar y confirmar un mensaje no demuestra que consumidor y productor interpreten igual estados, unidades o versiones. Ese canonical aborda el contrato entre participantes; aquí permanecen las responsabilidades de entrega y efecto.

Preguntas para revisar el diseño

• ¿Qué pasa entre commit local, publicación y checkpoint del relay?
• ¿Permanece la identidad de aplicación al republicar o redrivear?
• ¿La marca de procesamiento y el efecto comparten transacción y arbitraje concurrente?
• ¿Qué ocurre con una API o correo que queda fuera de ese commit?
• ¿El horizonte de retención admite el replay que operación puede ejecutar?
• ¿Quién detecta y recupera backlog, mensajes no publicables y casos en DLQ?
• ¿Una reintroducción tardía sigue siendo válida y respeta el orden necesario?

Conexiones y alcance

event-driven-architecture examina la significancia de eventos en interacción y reacción. Este mapa examina entrega, repetición y recuperación, también para comandos. Reliable Messaging soporta EDA sin definirla; Outbox, Inbox y DLQ son mecanismos con fronteras propias, no requisitos universales del profile.

saga-pattern coordina pasos y compensaciones del negocio; puede usar mensajería y outbox en pasos locales. Saga no es un broker ni reemplaza el relay. distributed-transactions compara contratos de coordinación; reliable-execution organiza las garantías de repetición y entrega.

load-and-flow-control permite revisar si el backlog representa un burst atendible o una insuficiencia sostenida. queue-management conecta límites y edad con responsabilidad durable; backpressure ayuda a evaluar si consumidores saturados consiguen frenar producción upstream, en lugar de trasladar la espera a otra cola.

retry define condiciones, presupuestos y responsabilidad de los intentos; resilience-patterns conecta esas decisiones con espera, espaciamiento y admisión. retry-topologies aplica ese contrato a residencia, programación y ordering de mensajes, y distingue reintento automático de recuperación operacional. Las fuentes, ejemplos y escenarios detallados permanecen en los documentos enlazados; este MOC ofrece navegación y síntesis.