Idempotency means that applying an operation repeatedly has the same effect as applying it once: f(f(x)) = f(x). In distributed systems, this property makes duplicate message processing safe. Combined with at-least-once delivery and processing, it can provide exactly-once processing semantics despite retries. section 4.5 section 4.7
Idempotency is application-specific and end-to-end: both sender and receiver must preserve the guarantee. A write-once register is inherently idempotent because later writes change nothing; charging a credit card is not, because a duplicate request can create a second charge. section 4.5 section 4.6
A common retry-safe design follows these steps:
- Generate a unique idempotence key, commonly a UUID, and attach it to the original request and every retry. section 4.5
- Have the receiver recognize repeated keys and return the previously recorded result rather than process the request again. section 4.5
- Record processing and request receipt transactionally so a crash cannot leave the system unsure whether the request was handled. section 4.5
Booking an airline ticket
A checkout request may time out after the payment processor charges the card, prompting the app to retry. Reusing one reservation-based idempotence key lets the processor return the original result instead of creating another charge. Without this protection, repeated app crashes can leave several pending charges. section 4.6
Listing 4.1 Transactional recording and processing
requests := { }
on message request do
if request in received then
return response
end
begin transaction #1
process(request) #2
received = received + request #2
commit transaction
return response
end
Shows transactional recording and processing as a compact receiver-side deduplication pattern. section 4.5
