# Idempotent Receiver

> Same message, same result — no matter how many times it is delivered.

- **Category**: Integration
- **Subcategory**: Messaging Endpoints
- **Canonical URL**: https://designpattern.fyi/patterns/idempotent_receiver/

---

## Description
Clean, reusable architecture pattern.


## Use Cases
Payment deduplication — PaymentProcessed messages arrive with a paymentId. Receiver checks the PROCESSED_PAYMENTS table before charging. If paymentId already exists — skip (network retry). If not — charge, insert paymentId. No double-charges even if the broker retries 5 times.





## Trade-offs


### Advantages

- Safe at-least-once delivery — duplicates handled transparently

- Protects against real-world duplicate delivery scenarios (retries, failovers)

- No code changes needed on the broker side

- Works with any broker that has at-least-once delivery guarantees




### Considerations & Drawbacks

- Processed ID store grows indefinitely without TTL or cleanup

- DB check on every message adds latency

- Idempotency window (how long to track IDs) must be explicitly defined

- Business logic must truly be idempotent — tracking IDs alone is not enough if logic has side effects







---
**Reference**: [Original Source](https://www.enterpriseintegrationpatterns.com/patterns/messaging/IdempotentReceiver.html)