Back to Catalog
Microservices
Messaging & Events
Idempotent Consumer
Handle the same message twice without screwing up — because at-least-once delivery is real.
Intent & Description
Real-world Use Case
AccountDebited message arrives twice (network retry). First delivery: balance updated, message ID stored. Second delivery: ID found in PROCESSED_MESSAGES → skipped. Balance correct. No double-debit.
Source
📌 TL;DR
At-least-once = duplicates will happen. Track message IDs, skip duplicates. Essential for any event-driven system that handles money or state.
Advantages
- Safe to use with at-least-once brokers (Kafka, SQS, RabbitMQ)
- Simple to implement with a dedup table
- No data corruption from retries or duplicate delivery
- Works with both choreography and orchestration sagas
Disadvantages
- PROCESSED_MESSAGES table grows unbounded — needs periodic cleanup
- Adds a DB read on every message receive (performance cost)
- Dedup window needs to be defined (how long to keep IDs?)
- Doesn’t help if business logic itself isn’t naturally idempotent