A customer taps Place order in your food-delivery app. Your service charges their card, starts writing the order, and then the response never makes it back across the network. The app gives up waiting and sends the request again, because that is the only move it has. Idempotency is the property that makes the second send harmless: repeating an operation produces the same externally visible effect as performing it once. Note what that says and what it doesn't. It is a claim about effects, not about the response bytes being identical, and not about the handler running only once.

In an interview this rarely arrives as its own question. It usually appears after you sketch a mutating endpoint or add a queue to the diagram: "the client timed out and retried, now what?" A mid-level answer names which endpoints need protection and the standard mechanism. A senior answer also examines the record itself, concurrent retries, and the boundary where the guarantee stops.

The topic matters because the failure is binary and visible: checking whether an order already exists sounds reasonable but still allows duplicate charges. The same concurrency problem appears on the request path and on the consumer side of a queue.