Publicar eventos de forma fiable con un outbox transaccional

Objetivo

Garantizar que todo cambio de estado confirmado (commit) produzca su evento exactamente cuando el cambio se confirma, sin una transacción distribuida entre la base de datos y el broker de mensajes.

Requisitos previos

Un servicio que es propietario de su base de datos y publica eventos en un broker; consumidores que toleran duplicados (deduplicando por id de mensaje). La página del patrón en microservices.io (citada) describe el problema: un servicio debe actualizar su base de datos y enviar un mensaje de forma atómica, y los mensajes de un mismo agregado deben mantener su orden entre instancias del servicio.

Pasos

1. Crear una tabla outbox: id (único, se convierte en el id del mensaje), aggregate_type, aggregate_id, event_type, payload (JSON), created_at y, solo para la variante de sondeo, published_at (que admite nulo). Los nombres de columna predeterminados de Debezium son id, aggregatetype, aggregateid, type y payload; otros nombres se mapean mediante sus opciones.
2. En la transacción de la aplicación que cambia el estado, insertar una fila de outbox por evento. Confirmar (commit). Nada más ocurre en la ruta de la solicitud.
3. Elegir un relay:
   • Publicador por sondeo: un worker selecciona las filas no publicadas en orden de id (FOR UPDATE SKIP LOCKED en PostgreSQL para permitir varios workers), publica cada una en el broker con el id de la fila como id de mensaje y el id del agregado como clave de partición, y luego fija published_at.
   • Seguimiento de log: un conector de captura de datos de cambios (CDC) lee el log de la base de datos. El enrutador de eventos de outbox de Debezium (citado) captura las inserciones en la tabla outbox, enruta cada fila a un topic derivado del tipo de agregado y usa el id del agregado como clave del mensaje. Su documentación indica que no se permiten actualizaciones a las filas de outbox y que las eliminaciones se filtran, de modo que con esta variante la tabla es solo de inserción: las filas se eliminan después, nunca se marcan.
4. Aceptar que una caída entre la publicación y el marcado (o, con seguimiento de log, entre la publicación y el registro de la posición por el conector) produce un duplicado; la idempotencia del productor del lado del broker, cuando se ofrece, cubre los reintentos dentro de una sesión de un mismo productor, no un relay reiniciado. Los consumidores deduplican por id de mensaje.
5. Eliminar o archivar las filas publicadas según un calendario; mantener la tabla pequeña para que la consulta de sondeo siga siendo económica.
6. Monitorizar la antigüedad de la fila no publicada más antigua y su recuento; alertar cuando el relay se detiene.

Resultado esperado

Ningún evento sin un cambio confirmado y ningún cambio sin un evento. Los consumidores ven cada evento al menos una vez, en orden por agregado si el relay conserva el orden de inserción y el broker conserva el orden por clave.

Límites y base de verificación

El sondeo añade una latencia de un intervalo de sondeo; el seguimiento de log necesita infraestructura de CDC y permisos de base de datos. No se garantiza el orden entre distintos agregados. Probar deteniendo el relay a mitad de lote y provocando una caída de la aplicación entre la escritura de negocio y el commit; el outbox no debe mostrar ni eventos huérfanos ni eventos faltantes.

Orden con un relay de sondeo

Varios workers de sondeo que usan SKIP LOCKED no conservan el orden por agregado: un worker puede publicar una fila posterior de un agregado antes de que otro worker publique una anterior, y una fila con un id menor puede volverse visible después de una fila con un id mayor porque las transacciones se confirman fuera de orden de id. Si los consumidores dependen del orden por agregado, ejecutar un único worker de publicación, o particionar los workers según un hash de aggregate_id para que las filas de un mismo agregado siempre las gestione el mismo worker, y sondear desde la fila no publicada más antigua en lugar de desde el último id visto. El relay de seguimiento de log evita ambos problemas porque lee los commits en el orden en que se confirman.