Outbox: transacciones, eventos y fallos parciales

Crear una orden y publicar OrderCreated suena como una operación. En realidad son dos sistemas: tu base de datos y tu broker. Entre uno y otro hay una grieta donde viven los fallos parciales.

El fallo clásico

1. insertar orden en DB            OK
2. commit                          OK
3. publicar OrderCreated al broker FALLA

La orden existe, pero nadie se enteró. Si el email, la facturación o el inventario dependían del evento, tu sistema queda inconsistente.

Tabla outbox mínima

CREATE TABLE outbox_events (
  id TEXT PRIMARY KEY,
  aggregate_type TEXT NOT NULL,
  aggregate_id TEXT NOT NULL,
  event_type TEXT NOT NULL,
  payload TEXT NOT NULL,
  status TEXT NOT NULL DEFAULT 'pending',
  created_at TEXT NOT NULL,
  published_at TEXT
);

En la misma transacción:

begin
  insertar orden
  insertar outbox_events(id, aggregate_id, event_type, payload)
commit

Worker reintentable

loop:
  eventos = buscar pending limit 100
  por cada evento:
    publicar al broker con event.id como idempotency key
    marcar published

Si el worker muere, vuelve a buscar pendientes. Si publica dos veces, el consumidor debe deduplicar por event.id.

Garantías honestas

problema                    respuesta
publish falla               queda pending y se reintenta
worker muere                otro worker retoma
evento duplicado            consumidor deduplica por id
orden rollback              no queda evento huérfano
broker recibe pero ack falla posible duplicado, no pérdida