รูปแบบ Outbox สำหรับการเผยแพร่ที่เชื่อถือได้

Saving to a database and publishing to RabbitMQ are two separate operations. If one succeeds and the other fails, your state and your events drift apart.

This is the dual-write problem.

The outbox pattern writes the business change and the outgoing message into the same database transaction, then publishes the message asynchronously from the outbox table.

Create a table that stores pending messages alongside your domain data.

In one transaction, update the business row and insert the outbox row. Either both commit or neither does.

A separate relay (or message dispatcher) polls the outbox for unpublished rows, publishes them to RabbitMQ, and marks them published.

The relay selects pending rows in order and publishes each one.

If the relay crashes after publishing but before marking the row, it republishes on restart. So consumers must be idempotent to tolerate duplicates.

Instead of polling, tools like Debezium tail the database write-ahead log and stream outbox inserts to RabbitMQ, reducing latency and load.

The relay should use publisher confirms so it only marks a row published after the broker acknowledges the message, closing the loss window.

The outbox guarantees a single service reliably emits its events. A saga coordinates a multi-service workflow. They complement each other: each saga step can publish via its own outbox.

• Periodically delete or archive published rows
• Index on published for fast polling
• Monitor relay lag to catch stalls early

Test your outbox understanding.

The outbox pattern stores outgoing messages in the same transaction as business data, then a relay publishes them to RabbitMQ asynchronously.

It eliminates the dual-write problem, requires idempotent consumers due to at-least-once delivery, and pairs well with publisher confirms and sagas.