---

Introduction

Imagine you're transferring $10,000 using your banking application.

You click:

Transfer Money

Immediately after clicking:

• Internet becomes slow
• Mobile application freezes
• You don't receive a response

You naturally click Transfer again.

Now imagine the backend processes both requests.

Result:

$10,000 Sent

↓

Again

↓

$10,000 Sent

↓

Total

$20,000

This is one of the most common problems in distributed systems.

Modern applications solve this using Idempotency.

Companies like:

• Amazon
• Stripe
• PayPal
• Uber
• Banking Applications

all implement idempotency to prevent duplicate operations.

---

Learning Objectives

After completing this article, you will understand:

• What is Idempotency?
• Why Idempotency Matters
• Safe vs Idempotent HTTP Methods
• Idempotency Keys
• Retry Mechanisms
• Payment Systems
• Event-Driven Idempotency
• Database Design
• Distributed Systems
• Best Practices

---

What is Idempotency?

Idempotency means:

Performing the same operation multiple times produces the same final result.

Example

Transfer Request

↓

Retry

↓

Retry

↓

Retry

↓

Only One Payment Created

---

Why Idempotency Matters

Modern systems experience:

• Network failures
• Timeouts
• Client retries
• Gateway retries
• Load balancer retries
• Kafka message redelivery

Without idempotency,

duplicate processing becomes inevitable.

---

Real-Time Banking Example

Customer clicks:

Pay ₹5000

Because of poor network,

the request is sent three times.

Without idempotency

Payment 1

Payment 2

Payment 3

↓

₹15,000 Debited

With idempotency

Payment

↓

Duplicate Request

↓

Same Transaction Returned

↓

₹5,000 Debited

---

Request Flow

flowchart LR

    A[Client]

    B[API Gateway]

    C[Payment API]

    D[(Database)]

    A --> B
    B --> C
    C --> D

---

Retry Scenario

flowchart LR

    A[Client]

    B[Request Timeout]

    C[Retry]

    D[Payment API]

    A --> B
    B --> C
    C --> D

Retries are common.

Duplicate processing must never happen.

---

Idempotency Flow

flowchart TD

    A[Incoming Request]

    B{Idempotency Key Exists?}

    C[Return Previous Response]

    D[Process Payment]

    E[Save Result]

    A --> B

    B --> C

    B --> D

    D --> E

---

Idempotency Key

Every request contains a unique identifier.

Example

POST /payments

Idempotency-Key:
4a8d5b7d-9876

The server stores

• Key
• Request
• Response

Future requests with the same key return the original response.

---

Request Example

POST /payments

Authorization: Bearer JWT

Idempotency-Key:
abc-123456

Content-Type: application/json

{
   "from":"10001",
   "to":"20001",
   "amount":500
}

---

First Request

Idempotency Key

↓

Not Found

↓

Process Payment

↓

Store Response

---

Second Request

Same Key

↓

Already Exists

↓

Return Stored Response

↓

No Duplicate Payment

---

Database Design

flowchart TD

    A[Payment API]

    B[(Idempotency Table)]

    C[(Payment Table)]

    A --> B

    A --> C

Idempotency Table

Column	Purpose
Key	Unique Identifier
Request Hash	Validation
Response	Cached Response
Status	Success/Failed
Created Time	Expiration

---

Example Table

Idempotency Key	Status
abc123	SUCCESS
xyz456	SUCCESS
pqr111	FAILED

---

Payment Processing

flowchart TD

    A[Customer]

    B[API Gateway]

    C[Payment Service]

    D[Idempotency Check]

    E[(Payment Database)]

    A --> B
    B --> C
    C --> D
    D --> E

---

Safe vs Idempotent Methods

Method	Safe	Idempotent
GET	✅	✅
PUT	❌	✅
DELETE	❌	✅
POST	❌	❌ (Unless Implemented)
PATCH	❌	Usually No

---

POST Without Idempotency

POST /orders

↓

Order Created

Retry

POST /orders

↓

Another Order Created

Duplicate order.

---

POST With Idempotency

POST /orders

↓

Order Created

↓

Retry

↓

Existing Order Returned

---

Event-Driven Systems

Kafka guarantees

At Least Once Delivery

This means

messages may be delivered multiple times.

---

Kafka Example

flowchart LR

    A[Producer]

    B[Kafka]

    C[Consumer]

    D[(Database)]

    A --> B
    B --> C
    C --> D

Consumer must ignore duplicate events.

---

Event Processing

flowchart TD

    A[Kafka Event]

    B{Already Processed?}

    C[Ignore]

    D[Process Event]

    A --> B

    B --> C
    B --> D

---

Banking Example

Money Transfer

Transaction ID

↓

TXN100001

↓

Retry

↓

Same Transaction ID

↓

No Duplicate Transfer

---

Amazon Example

Customer clicks

Place Order

Internet freezes.

Customer clicks again.

Amazon returns

Order Already Created

instead of creating another order.

---

Stripe Example

Stripe API requires

Idempotency-Key

Every payment request can be safely retried.

---

Uber Example

Ride Booking

Ride Request

↓

Retry

↓

Same Ride Returned

No duplicate drivers.

---

Distributed Systems

flowchart TD

    A[API Gateway]

    B[Order Service]

    C[Payment Service]

    D[Inventory Service]

    E[(Database)]

    A --> B

    B --> C
    B --> D

    C --> E
    D --> E

Every critical service should support idempotency.

---

Retry Architecture

flowchart LR

    A[Client]

    B[Retry]

    C[API Gateway]

    D[Spring Boot]

    A --> B
    B --> C
    C --> D

Retries become safe because duplicate operations are prevented.

---

Idempotency vs Duplicate Detection

Idempotency	Duplicate Detection
Prevents duplicate execution	Finds duplicates after processing
Happens before processing	Happens after processing
Better user experience	More expensive

---

Common Use Cases

Implement idempotency for:

• Payments
• Order Creation
• Loan Applications
• OTP Generation
• Ticket Booking
• Wallet Recharge
• Inventory Updates
• Kafka Consumers

---

Spring Boot Architecture

flowchart TD

    A[React UI]

    B[API Gateway]

    C[Spring Boot]

    D[Redis]

    E[(PostgreSQL)]

    A --> B
    B --> C
    C --> D
    C --> E

Redis is commonly used to store temporary idempotency keys for fast lookups.

---

Monitoring

Monitor

• Duplicate Requests
• Retry Count
• Idempotency Key Usage
• Payment Failures
• Duplicate Events
• Kafka Redelivery
• API Latency
• Error Rate

Tools

• Datadog
• Prometheus
• Grafana
• CloudWatch

---

Common Mistakes

❌ Ignoring retries

❌ Using POST without idempotency

❌ No unique transaction ID

❌ Processing duplicate Kafka events

❌ Not expiring old idempotency keys

❌ Returning different responses for the same key

---

Best Practices

• Generate a unique Idempotency-Key for every client request.
• Store request metadata with the response.
• Expire old keys after an appropriate retention period.
• Use Redis for fast key lookups.
• Implement idempotent consumers for event-driven systems.
• Ensure payment APIs are always idempotent.
• Combine retries with exponential backoff.
• Log duplicate requests for monitoring and auditing.

---

Common Interview Questions

What is Idempotency?

Idempotency is the property where executing the same operation multiple times produces the same final result.

---

Why is idempotency important in payment systems?

It prevents duplicate charges when clients retry requests because of network failures or timeouts.

---

Is HTTP POST idempotent?

No. By default, POST is not idempotent. It can be made idempotent by using an Idempotency-Key and storing the result of the initial request.

---

Why is idempotency important in Kafka consumers?

Kafka provides at-least-once delivery, meaning the same message may be delivered multiple times. Consumers must ensure duplicate events are not processed more than once.

---

Why is Redis commonly used for idempotency?

Redis offers very fast in-memory lookups, making it ideal for storing temporary idempotency keys with configurable expiration times.

---

Summary

Idempotency is one of the most important concepts in distributed systems. It ensures that retries caused by network failures, client errors, or message redelivery do not result in duplicate business operations.

In this article, we covered:

• Idempotency fundamentals
• Retry scenarios
• Idempotency keys
• HTTP method behavior
• Database design
• Kafka event processing
• Payment systems
• Banking, Amazon, Stripe, and Uber examples
• Monitoring
• Best practices

Implementing idempotency correctly is essential for building reliable, fault-tolerant, and financially safe systems, especially when handling payments, orders, messaging, and other critical business operations.

---