Transactional Outbox Pattern

TL;DR

Explanation

Problem: update DB and publish message — if broker publish fails after DB commit, event is lost. Solution: write to an 'outbox' table in the same DB transaction as the domain data. A separate relay process reads the outbox and publishes to the broker, deleting rows after confirmed publish. This achieves atomic write-to-DB and guaranteed eventual publish. CDC (Change Data Capture): use Debezium to read DB transaction log and publish to Kafka — no outbox table needed. Polling relay: simpler, slight delay. Event store: Kafka as the source of truth (event sourcing). Implementations: Symfony Messenger Doctrine transport, Transactionally Outbox libraries.

Common Misconception

Why It Matters

Common Mistakes

• Dual-write without outbox — publish to broker then DB commit (or vice versa) can leave them inconsistent.
• Not cleaning up old outbox rows — table grows unboundedly.
• Relay not idempotent — duplicate publish on relay restart.

Code Examples

// Dual-write — inconsistent on failure:
$db->beginTransaction();
$db->insert('orders', $orderData);
$db->commit();
$broker->publish('order.created', $event); // Fails? Event lost.

// Outbox pattern:
$db->beginTransaction();
$db->insert('orders', $orderData);
$db->insert('outbox', [
    'topic' => 'order.created',
    'payload' => json_encode($event),
    'created_at' => now(),
]);
$db->commit();
// Relay process reads outbox and publishes asynchronously
// Idempotent: broker publish + delete outbox row

References

• ↗ https://microservices.io/patterns/data/transactional-outbox.html

Tags

Related Terms