Skip to content

Outbox Pattern

Spicy — senior dev territoryArchitecture

ELI5 — The Vibe Check

The outbox pattern solves the 'I need to update my database AND send an event, but what if one succeeds and the other fails?' problem. Instead of sending the event directly, you write it to an 'outbox' table in the same database transaction as your data change. A separate process reads the outbox and publishes the events. Both succeed or both fail. Data consistency is preserved.

Real Talk

The Outbox Pattern (also called Transactional Outbox) ensures reliable event publishing alongside database changes by writing domain events to an outbox table within the same database transaction as the business data. A separate relay process (using polling or CDC — Change Data Capture via tools like Debezium) reads the outbox table and publishes events to the message broker. This guarantees at-least-once delivery without distributed transactions.

Show Me The Code

-- Within the same transaction:
BEGIN;
  INSERT INTO orders (id, status) VALUES ('ord-123', 'created');
  INSERT INTO outbox (id, event_type, payload)
    VALUES (gen_random_uuid(), 'OrderCreated',
      '{"orderId": "ord-123", "status": "created"}');
COMMIT;

-- Separate relay process polls outbox and publishes to Kafka/RabbitMQ

When You'll Hear This

"Use the outbox pattern to guarantee the order event gets published." / "Debezium reads our outbox table via CDC — no polling needed."

Made with passive-aggressive love by manoga.digital. Powered by Claude.