Idempotency is one of the most important reliability concepts in API design. This guide covers what it means, which HTTP methods are idempotent, how to make POST requests safe to retry, and the questions interviewers ask about it.

Interview Questions and Answers

1. What is idempotency in REST APIs?

Answer:

Idempotency means that performing the same operation multiple times produces the same intended final state as performing it once.

For example:

• Calling PUT /customers/101 multiple times with the same payload leaves the customer in the same state.
• Retrying a payment request with the same Idempotency-Key should create only one payment, not multiple payments.

Idempotency is critical in distributed systems where network failures and retries are common.

---

2. Why is idempotency important?

Answer:

Without idempotency, retries may create duplicate business operations.

Examples include:

• Duplicate payments
• Duplicate money transfers
• Multiple hotel bookings
• Duplicate order creation
• Multiple insurance claims

Idempotency ensures reliability when:

• Network timeouts occur
• Clients automatically retry
• API gateways retry requests
• Kafka redelivers messages
• Users accidentally click the Submit button multiple times

---

3. Which HTTP methods are idempotent?

Answer:

Method	Idempotent	Reason
GET	✅ Yes	Reads data without changing state
PUT	✅ Yes	Replaces the resource
DELETE	✅ Yes	Resource remains deleted after the first request
HEAD	✅ Yes	Retrieves headers only
OPTIONS	✅ Yes	Retrieves supported operations
POST	❌ No	Usually creates a new resource
PATCH	Depends	Depends on the update operation

---

4. Is POST always non-idempotent?

Answer:

No.

By default, POST is not idempotent, but it can be made idempotent using an Idempotency-Key.

Example:

POST /payments
Idempotency-Key: abc123

If the same request is retried with the same key, the server returns the original response instead of creating another payment.

---

5. What is an Idempotency-Key?

Answer:

An Idempotency-Key is a unique identifier generated by the client for a logical operation.

Example:

POST /payments
Idempotency-Key: 4df9e64f-78bb-48d2-92d1-ae4e55f95ef0

The server stores:

• Idempotency key
• Request hash
• Processing status
• Response
• Resource ID
• Expiration time

When the same key is received again, the server returns the stored response instead of executing the operation again.

---

6. Why should the client generate the Idempotency-Key?

Answer:

The client may not receive the original response because of:

• Network timeout
• Gateway timeout
• Lost response
• Connection reset

Since the client already knows the key, it can safely retry the request using the same key.

If the server generated the key, the client would not know it after a timeout.

---

7. What happens if the same Idempotency-Key is used with a different request payload?

Answer:

The server should reject the request because the key represents one logical operation.

Example:

First request:

{
  "amount": 100
}

Retry:

{
  "amount": 500
}

Recommended response:

409 Conflict

This prevents accidental or malicious reuse of idempotency keys.

---

8. How do you prevent duplicate processing when two identical requests arrive simultaneously?

Answer:

The key must be reserved atomically.

Common approaches include:

• Database unique constraints
• Atomic INSERT statements
• Redis SET NX
• Distributed locks
• Compare-and-set operations

Simply checking if a key exists before inserting is not sufficient because two requests may execute concurrently.

---

9. What information should be stored in an idempotency record?

Answer:

A typical record includes:

• Client ID
• Idempotency-Key
• Request hash
• Request path
• Processing status
• HTTP response status
• Response body
• Resource ID
• Creation timestamp
• Expiration timestamp

This allows the server to replay the original response for duplicate requests.

---

10. How long should an Idempotency-Key be stored?

Answer:

The retention period depends on business requirements.

Typical examples:

• Standard order APIs: 24 hours
• Payment APIs: 24–72 hours
• Financial settlement references: Longer, depending on regulations

The retention period should be longer than the maximum expected retry window.

---

11. How do you implement idempotency using Redis?

Answer:

Redis provides atomic key creation using:

SET payment:abc123 IN_PROGRESS NX EX 86400

Where:

• NX ensures the key is created only if it does not already exist.
• EX sets the expiration time.

If the command succeeds, the request proceeds.

If it fails, another request has already reserved the key.

Redis is very fast but is often combined with a durable database for financial transactions.

---

12. How is idempotency implemented in Kafka consumers?

Answer:

Kafka uses at-least-once delivery, so the same event may be delivered multiple times.

A common approach is to maintain a table of processed event IDs.

Flow:

1. Receive event.
2. Check whether eventId already exists.
3. If it exists, ignore the event.
4. Otherwise, process the event.
5. Store the event ID.
6. Commit the transaction.

This prevents duplicate business processing even if Kafka redelivers the message.

---

13. What is the difference between idempotency and optimistic locking?

Answer:

Idempotency	Optimistic Locking
Prevents duplicate execution of the same request	Prevents concurrent updates from overwriting each other
Used for retries	Used for concurrent modifications
Uses Idempotency-Key	Uses version numbers or ETags

Both patterns solve different problems and are often used together.

---

14. What are common mistakes when implementing idempotency?

Answer:

Some common mistakes include:

• Checking the key without atomic reservation
• Storing keys only in application memory
• Generating keys on the server
• Reusing the same key for different operations
• Not validating request payloads
• Expiring keys too early
• Ignoring concurrent requests
• Not storing the original response
• Blindly retrying external payment providers
• Assuming Redis alone guarantees consistency

These mistakes can still result in duplicate business transactions.

---

15. How would you design an idempotent payment API in a production system?

Answer:

A production-grade payment API would include:

1. Client-generated Idempotency-Key.
2. Request fingerprint validation.
3. Atomic key reservation using a database unique constraint or Redis SET NX.
4. Processing status tracking (IN_PROGRESS, COMPLETED, FAILED).
5. Durable storage of the response.
6. Replay of the original response for duplicate requests.
7. Rejection of the same key with different payloads.
8. Stable transaction references for downstream payment providers.
9. Recovery and reconciliation for uncertain outcomes.
10. Monitoring, logging, and metrics for duplicate detection.

This approach ensures that retries never create duplicate financial transactions while maintaining high availability and reliability.

---

Senior-Level Interview Tip

When asked about idempotency in interviews, explain it from a distributed systems perspective rather than only defining the term.

A strong answer should mention:

• Network failures
• Automatic retries
• Duplicate request prevention
• Idempotency-Key
• Atomic reservation
• Request fingerprint
• Redis or database unique constraints
• Payment APIs
• Kafka duplicate events
• External system reconciliation

This demonstrates practical production experience rather than theoretical knowledge.