Transactional Outbox and Change Data Capture

Writing to the database and publishing to a broker are two systems — a crash between them loses or invents events (the dual-write problem). The transactional outbox writes the event into an outbox table in the same transaction; a relay publishes it afterwards (polling with FOR UPDATE SKIP LOCKED, or CDC with Debezium reading the database log). Consumers stay idempotent because relays may publish twice.

BEGIN;
  INSERT INTO orders (id, status, total) VALUES ('ord_1', 'paid', 2400);
  INSERT INTO outbox (id, aggregate_id, type, payload)
    VALUES (gen_random_uuid(), 'ord_1', 'order.paid', '{"order_id":"ord_1","total":2400}');
COMMIT;

-- relay (poller)
SELECT * FROM outbox WHERE published_at IS NULL ORDER BY created_at LIMIT 100 FOR UPDATE SKIP LOCKED;
-- publish each, then UPDATE outbox SET published_at = now() WHERE id = ...

Common pitfalls

• Publishing inside the DB transaction (broker down → transaction blocked).
• Outbox tables growing unbounded.
• Assuming global ordering across aggregates.

Key points

• Outbox solves dual writes
• Polling relay or CDC
• Consumers stay idempotent

Further reading: microservices.io: Transactional outbox