Derive or read an idempotency key that represents the logical business operation rather than the transport attempt.
Enterprise Messaging · Messaging Endpoints
Idempotent Receiver
Design processing so receiving the same message more than once has the same effect as receiving it once, usually through deduplication or naturally idempotent operations.
How can a message receiver deal with duplicate messages?Adapted from Enterprise Integration Patterns under CC BY 3.0. The visualization and explanatory content on this page are original GateSift material.
Original GateSift visualization
How Idempotent Receiver works
A stable identity and atomic completion record prevent repeated delivery from repeating the protected business effect.
Possibly repeated delivery
Check stable identity
Process once
Ignore duplicate
Check and record completion atomically with the side effect whenever possible.
Return the prior outcome or safely ignore later deliveries while retaining evidence for the required replay window.
Curated GateSift guidance
When this pattern is a good fit — and when it is not
Use idempotent receiving when the same logical message may arrive more than once and repeating its business effect would be incorrect or expensive.
- The transport or retry policy can redeliver messages.
- The handler performs non-idempotent side effects such as creating orders, payments or files.
- A stable business or message identifier can be used to recognize prior completion.
- The operation is naturally idempotent and duplicate execution has no additional effect.
- There is no reliable identity for deciding whether two deliveries represent the same logical operation.
- Deduplication state would expire before legitimate redelivery can occur.
False duplicateHigh impact
Using a weak key can suppress a legitimate new business operation that happens to look similar.
Race conditionHigh impact
Concurrent duplicate deliveries can both pass a non-atomic existence check before either records completion.
State growthReview
Deduplication records need an explicit retention strategy based on replay and business windows.
- Prefer a business idempotency key or immutable message identifier over a hash of the whole payload.
- Store the deduplication decision atomically with the business state where possible, or use a transactional boundary that prevents two winners.
- Service Bus duplicate detection can reduce transport duplicates, but application-level idempotency is still needed for end-to-end side effects.
What this pattern helps you decide
Design processing so receiving the same message more than once has the same effect as receiving it once, usually through deduplication or naturally idempotent operations.
What identifier proves two deliveries represent the same business operation?
Is the duplicate check atomic with the side effect it protects?
How long must idempotency evidence be retained to cover retries, replay and disaster recovery?
Where you may see it
- Service Bus duplicate detection
- Inbox table keyed by message ID
- Idempotent PUT/upsert
How the analyzers can surface it
- Correlation and message IDs
- Retry without deduplication warning
Pattern detection is contextual. GateSift should present these as architectural signals, not claim a pattern is implemented solely because one policy statement or adapter exists.
Source, licence and attribution
The pattern name and selected problem statement are adapted from Enterprise Integration Patterns by Gregor Hohpe and Bobby Woolf under CC BY 3.0. GateSift summaries, Azure mappings, analyzer guidance and diagrams are original. No endorsement by the original authors is implied.