Duplicates are normal
Most event systems deliver at least once, meaning an event can arrive more than once after retries or redelivery. A consumer is idempotent when processing the same event twice has the same effect as processing it once.
Ways to achieve it
- Track processed ids. Store each event id in a table and skip ids you have already handled.
- Natural idempotency. Design operations so repeating them is harmless, such as setting a field to a value rather than incrementing.
- Conditional writes. Apply a change only if the current version matches what the event expects.
Making it atomic
The business change and the record of the event id should commit together. Otherwise a crash between them can either reprocess or lose the event. Keeping both in one transaction closes that gap.
Key idea
Idempotent consumers make repeated delivery safe by detecting already handled events or designing operations whose repetition does not change the result.