การสร้างตัวรับเหตุการณ์ที่ไม่ขึ้นต่อการทำซ้ำ

In a choreography saga, services react to events from a broker. Brokers deliver at least once, so the same event can arrive twice — and sometimes out of order. Naive handlers double-charge or double-ship.

An idempotent consumer can process the same event repeatedly with no extra effect. This is essential for correctness in any event-driven saga.

Give every event a unique id. Before handling, check whether you have already processed that id; if so, skip and acknowledge.

The inbox pattern stores processed event ids in a table inside the same database transaction as the business change. Insert + work commit together, so a redelivery is rejected by the unique constraint.

If you ack the event but crash before committing the business change, the work is lost. Doing both in one transaction guarantees they succeed or fail together.

A participant must often update its DB and publish a new event. Doing these as two separate calls risks one succeeding and the other failing — the classic dual-write problem.

The outbox pattern solves it: write the outgoing event into an outbox table in the same transaction as the business change. A separate relay publishes from the outbox to the broker.

A poller or change-data-capture (CDC) tool like Debezium reads new outbox rows and publishes them, then marks them sent. Publishing is at-least-once, so downstream consumers must be idempotent too.

Events may arrive out of order. Use version numbers or sequence ids and ignore stale events, or design handlers that converge to the correct state regardless of order.

When a saga fails, compensating events also flow through the broker and can be redelivered. A compensation (e.g. refund) must itself be idempotent, or you refund twice.

A robust choreography participant: consume via the inbox (dedup), do work and write the outbox in one transaction, relay the outbox to the broker, and make every handler — including compensations — idempotent.

You hardened choreography consumers:

• Brokers deliver at-least-once, so events repeat and may reorder
• Idempotent consumers process duplicates safely
• The inbox pattern dedups within the business transaction
• The outbox pattern solves the dual-write problem; a relay/CDC publishes it
• Handle out-of-order events and make compensations idempotent too