# Idempotent Consumer

> Handle the same message twice without screwing up — because at-least-once delivery is real.

- **Category**: Microservices
- **Subcategory**: Messaging & Events
- **Canonical URL**: https://designpattern.fyi/patterns/idempotent_consumer/

---

## Description
Clean, reusable architecture pattern.


## Use Cases
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.





## Trade-offs


### 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




### Considerations & Drawbacks

- 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







---
**Reference**: [Original Source](https://microservices.io/patterns/communication-style/idempotent-consumer.html)