Transactional Outbox

El patrón Transactional Outbox guarda un cambio en los datos de negocio y un registro persistente del mensaje saliente en una misma transacción local de base de datos. Un proceso independiente, el relay, lee esos registros y los publica en el intermediario de mensajes. Así se cubre el intervalo en el que la transacción ya se ha confirmado, pero la aplicación no llega a intentar el envío posterior.

En un ejemplo ficticio, el ticket de soporte S-27 pasa al estado «cerrado». El servicio guarda juntos el nuevo estado y el evento E-27. Si falla la transacción, se revierten ambos cambios. Si se confirma y después el servicio se interrumpe, el evento queda registrado para publicarlo más tarde.

Publicar y procesar son pasos separados

Si el relay publica E-27 y se interrumpe antes de registrar el éxito, puede volver a publicar el mensaje. El destinatario debe gestionar las entregas repetidas sin duplicar su efecto, por ejemplo mediante una Transactional Inbox. La outbox por sí sola no garantiza un efecto exactamente una vez entre la base de datos, el intermediario y el destinatario.

Defina cómo encontrar los registros pendientes, hacer visibles los fallos y, cuando sea necesario, mantener el orden de publicación de los eventos de cada ticket. Prevea también la limpieza y la recuperación. CDC puede servir de base técnica para el relay; capturar cambios de filas no define por sí mismo un evento de negocio.

Fuentes

• Chris Richardson — Transactional Outbox