Identify the payload or state that must survive beyond the current processing attempt.
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
The integration persists data or processing state so it can be recovered, deduplicated or retrieved later.
Message or payload
Idempotent Receiver
Durable reference / state
Apply Idempotent Receiver to persist, reference or verify that state.
Retrieve or reuse the stored information when the flow continues or recovers.
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 happens when processing fails or the same message is delivered twice?
Where does state, correlation or routing configuration live?
How will operators trace the message and understand the decision path?
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.