รูปแบบเอาต์บ็อกซ์แบบทรานแซกชัน

A common bug: a service updates its database and publishes a Kafka event in two separate operations. If one succeeds and the other fails, the system becomes inconsistent.

The transactional outbox pattern eliminates this risk.

Instead of publishing directly, write the event into an outbox table within the same database transaction as your business change.

A separate process then reads the outbox and publishes to Kafka.

The outbox table stores serialized events plus metadata.

Both the domain entity and the outbox row are saved inside one @Transactional method, so they commit or roll back together.

Because both writes share the database transaction, there is no window where the order exists without its event recorded. This is the key correctness property.

A background relay polls unpublished outbox rows and sends them to Kafka, marking them published on success.

If the relay crashes after sending but before marking published, the event is sent again. Consumers must therefore be idempotent, often using the event id as a dedup key.

Instead of polling, tools like Debezium tail the database transaction log and stream outbox inserts to Kafka automatically — lower latency and no polling load.

Periodically delete or archive published rows to keep the table small and queries fast.

Use the outbox when you must keep a database state change and an event publication consistent. It is simpler and more portable than spanning a Kafka transaction across an external database.

The outbox pattern turns two unreliable writes into one atomic database commit plus a reliable relay. Combine it with idempotent consumers for end-to-end consistency.

You learned the transactional outbox pattern.

• Avoids dual-write inconsistency by using one DB transaction.
• An outbox table stores pending events.
• A relay (polling or CDC) publishes to Kafka.
• Consumers must be idempotent due to at-least-once delivery.