An operation is idempotent if performing it multiple times has the same effect as doing it once.
In distributed systems and APIs, failures or retries are common. Idempotency ensures that reprocessing a request (e.g., due to a timeout or client retry) doesn’t cause unintended side effects like duplicate charges or records.
Use idempotency when building APIs or services where clients might retry requests - especially for operations like payments, updates, or resource creation.
You need to know
Idempotency key helps track requests: Clients often send a unique key (like a UUID) with each request, so the server can detect and discard duplicates.
Not all HTTP methods are idempotent:
GET,PUT, andDELETEare typically idempotent;POSTis not unless explicitly handled that way.Applies to side effects, not just responses: It’s ensuring the system state doesn’t change undesirably, not just returning the same result.
Like posts like this?
Every week, you'll get a new system design concept, broken down like this one.
Free subscribers also get a little bonus:
🎁 The System Design Interview Preparation Cheat Sheet
If you're into visuals, paid subscribers unlock:
→ My Excalidraw system design template – so you have somewhere to start
→ My Excalidraw component library – used in the diagram of this issue
No pressure though. Your support helps me keep writing, and I appreciate it more than you know ❤️