- Idempotency means performing the same operation multiple times produces the same result as performing it once.
- It ensures safe retries in distributed systems, APIs, and microservices.
| Operation | Idempotent? | Explanation |
|---|---|---|
GET /user/123 |
✅ Yes | Always returns the same user data (no state change). |
DELETE /user/123 |
✅ Yes | Deleting the same user again has no effect after the first time. |
POST /user |
❌ No | Creates a new user every time — changes system state. |
PUT /user/123 |
✅ Yes | Replaces user data with the same payload every time. |
- Prevents duplicate side effects (e.g., double payments, double orders).
- Enables safe retries in case of network or service failures.
- Makes APIs more reliable and predictable.
-
Idempotency Key:
- Assign a unique request ID (e.g.,
idempotency-key: 12345) to ensure repeated requests don’t duplicate actions. - Used in payment APIs (like Stripe, PayPal).
- Assign a unique request ID (e.g.,
-
State Check Before Action:
- Check if an operation has already been performed before executing it again.
-
PUT Instead of POST:
- Prefer
PUTfor resource updates since it’s naturally idempotent.
- Prefer
-
Database Constraints:
- Use unique constraints (like unique order IDs) to prevent duplicates.
- A stateless system does not store any information (state) about the client between requests.
- Each request contains all necessary context to process it.
| Stateful System | Stateless System |
|---|---|
| Server stores user session data. | Client sends auth token (JWT) in every request. |
| Load balancer must route user to same server. | Any server can handle any request. |
| Example: Traditional web servers with in-memory sessions. | Example: REST APIs, Serverless apps. |
-
Scalability: Any server can handle any request.
-
Fault Tolerance: No session loss if one server fails.
-
Simplicity: Easier to maintain and scale horizontally.
-
Improved Load Balancing: Traffic can freely move across servers.
-
Client Overhead: Client must send all context each time.
-
No Session Persistence: Hard to maintain login state without tokens.
-
Data Re-fetching: Increases network traffic for repeated data.
-
Use JWT tokens or API keys for authentication.
-
Store state externally (e.g., in Redis, DB, or client-side cookies).
-
Design APIs to be stateless and idempotent for reliability.
| Aspect | Idempotency | Statelessness |
|---|---|---|
| Definition | Repeating same request gives same result. | Server doesn’t store client context. |
| Focus | Operation safety. | Server-side design. |
| Example | DELETE /user/123 multiple times → OK. |
Each API call includes JWT token. |
| Goal | Prevent duplicate actions. | Enable scalability and independence. |
| Common Use | Payment systems, API retries. | REST APIs, Microservices, Serverless. |