Idempotency

An operation is idempotent when applying the same intended request more than once has the same externally meaningful effect as applying it once. Repetition may still consume CPU, produce logs, or update internal metadata; the protected business result does not multiply.

Interview relevance

Idempotency matters whenever clients, queues, workers, or operators may retry after a timeout without knowing whether the first attempt completed. A payment endpoint that accepts an idempotency key can return the original result instead of creating a second charge. A consumer can record a processed event identifier before applying a non-repeatable side effect.

Calling an HTTP method idempotent does not make an implementation safe automatically. The key scope, retention window, concurrency behavior, stored response, and downstream side effects must all be defined.

Useful test

Send the same logical request concurrently and after a simulated timeout. Verify that the protected state changes once, every caller receives a coherent result, and the deduplication record survives long enough for the retry window.