Outbox Pattern

Resumen

El patrón Outbox resuelve el problema de atomicidad entre escritura de datos y publicación de eventos. Si un servicio guarda una orden en su base de datos y después publica el evento OrderCreated en un message broker, puede pasar que la escritura a la base de datos falle después de publicar el evento —el sistema cree que la orden existe y no es cierto—, o que la publicación falle después de escribir —la orden existe pero nadie lo sabe—.

La solución: en lugar de escribir en la base de datos y publicar al broker en dos pasos, el servicio escribe tanto el cambio de estado como el evento en la base de datos, dentro de la misma transacción. Una tabla outbox guarda los eventos pendientes de publicación. Un proceso separado —el outbox publisher— lee esa tabla y publica los eventos al broker. Si algo falla, la transacción se revierte completa.

Alcance y supuestos

Este paquete cubre el concepto a nivel arquitectónico: qué es, qué problema resuelve, cómo se relaciona con otros patrones del ecosistema, y en qué contexto tiene sentido aplicarlo. No cubre detalles de implementación específicos de cada tecnología ni configuraciones de proveedores cloud concretos. Asume que el lector entiende los fundamentos de sistemas distribuidos y arquitectura de software.

Modelo mental

El libro de envíos de una oficina de correos. Cuando despachás un paquete, el empleado anota el envío en un libro. Al final del día, otro empleado toma el libro y manda las notificaciones de «su paquete fue despachado». Si la computadora falla, los paquetes igual están anotados en el libro y las notificaciones se mandan cuando el sistema vuelve. La transacción —anotar el paquete— y la notificación no son simultáneas, pero el libro garantiza que nada se pierde.

Uso práctico

• ✅ Atomicidad: el cambio de estado y el evento persisten juntos o no persiste ninguno.
• ✅ Confiabilidad: incluso si el broker está caído, los eventos quedan en la tabla outbox y se publican cuando vuelve.
• ❌ Latencia adicional: entre la escritura y la publicación hay una demora —el ciclo del outbox publisher—.
• ❌ Complejidad operativa: requiere mantener la tabla outbox y el proceso de publicación.

Alternativas: Transactional Outbox (el patrón descrito), Change Data Capture (usar el log de la base de datos —Debezium, por ejemplo— para detectar cambios y publicarlos), y Event Sourcing (el log de eventos es la fuente de verdad).

Ejemplo trabajado: outbox en un servicio de usuarios

El servicio user-service registra un usuario nuevo y debe publicar UserRegistered para que email-service envíe un correo de bienvenida. En la misma transacción de base de datos, user-service inserta la fila en users y una fila en outbox con el evento. Un worker lee la tabla outbox cada 500 ms, publica los eventos pendientes en Kafka y los marca como enviados. Si Kafka está caído, los eventos quedan en outbox y se publican cuando Kafka vuelve. Ningún usuario dejó de recibir su email de bienvenida por una falla transitoria.

Evidencia

• Microsoft Azure Architecture Center, Cloud Design Patterns documenta el patrón Transactional Outbox como solución al problema de dual writes en sistemas distribuidos.