Skip to content
HLD Learn/Distributed Transactions & Resilience

Idempotency & Exactly-Once Illusions

4 min read

You'll learn to

  • -Explain why "exactly-once" delivery is mostly a myth, and how idempotency fixes it

Why "Exactly-Once" Is Mostly a Myth

Back in the Asynchronous Systems module, at-least-once delivery was named as the practical default for most queues, and the same reality applies to retries in general: a network timeout doesn't tell you whether the server actually processed your request or not, so a client retrying "to be safe" might be sending a duplicate of a request that already succeeded.

Idempotency Keys

The fix isn't preventing duplicates: it's making duplicates harmless. The client generates a unique key for each logical operation (a specific payment attempt, say) and sends it with the request. The server remembers keys it has already processed and, if it sees the same key again, returns the original result instead of executing the action a second time, so retrying a payment can never double-charge the customer.

This is the same idea from the Dead Letter Queue chapter, applied at the request/response level instead of the message-queue level: "exactly-once" in practice almost always means "at-least-once delivery, with an idempotent receiver."

Client
Web Server
Processed Keys
Database

The server checks the idempotency key against a store of already-processed requests before executing anything new.

ClientWeb Server- request + idempotency keyWeb ServerProcessed Keys- seen this key before?Web ServerDatabase- only if new
Interview Signal

A client retries a "charge $50" request with the same idempotency key after a timeout. The original request actually succeeded but the response never reached the client. What happens?

Weak Answer

"The server processes it again since the client never got confirmation."

Strong Answer

"The server should recognize the idempotency key as already processed and return the ORIGINAL result (a successful charge confirmation) without charging the card again. That's the entire point of the key: the client legitimately doesn't know if its first request succeeded, so it retries 'to be safe,' and the server's job is to make that retry harmless rather than trying to prevent the client from ever retrying."

Check Yourself1 / 3

What causes a cascading failure?

Ready to Build This?

Level 17: Hotel Reservation is a textbook SAGA/resilience exercise.

ScaleDojo Logo
Initializing ScaleDojo