Back to Catalog
Integration
Messaging Endpoints
Idempotent Receiver
Same message, same result — no matter how many times it is delivered.
Intent & Description
Real-world Use Case
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.
Source
📌 TL;DR
Idempotent Receiver = process once, even if delivered multiple times. Track message IDs, skip duplicates. Non-negotiable for any consumer receiving money, state changes, or critical operations.
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
Disadvantages
- 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