What is Idempotency?

👉 Idempotency means: Performing the same operation multiple times gives the same result as performing it once.

• In Math: Example: abs(abs(x)) = abs(x) (abs is idempotent, no matter how many times you apply it).

• In APIs / System Design: An idempotent API/operation is one where repeated requests do not create different side effects.

  • Example: DELETE /user/123 → Whether you call it once or 10 times, user 123 is gone.
  • Example: PUT /order/45 {status: SHIPPED} → Whether you send this request once or 5 times, order 45 will always be SHIPPED.

---

Idempotency in System Design

It’s super important in distributed systems because failures, retries, and network glitches are common.

Where it helps

1. API Reliability

   • If a client retries a request (due to timeout or network error), an idempotent API ensures the state isn’t corrupted.
   • Example: Payment APIs → You don’t want to charge a customer twice if they clicked “Pay” twice or system retried.

2. Fault Tolerance in Distributed Systems

   • Systems like message queues or microservices often retry events.
   • Without idempotency → you may process the same event twice.
   • With idempotency → multiple deliveries are safe.

3. Database Operations

   • INSERT is usually not idempotent (adding duplicates).
   • UPSERT (insert if not exists, else update) is idempotent.
   • DELETE or UPDATE by unique ID is idempotent.

---

How to Implement Idempotency

• Idempotency Keys

  • Client generates a unique key for each operation (e.g., payment request).
  • Server stores this key → If same key comes again, server returns the same response without duplicating work.

• Upsert instead of Insert

  • Example: INSERT INTO payments (id, amount) → risk of duplicates.
  • Instead use: INSERT ... ON CONFLICT DO NOTHING or UPDATE with unique ID.

• Design APIs carefully

  • Use PUT (replace resource) instead of POST (create new resource) where possible.

---

Example

Imagine a payment service:

• User clicks “Pay ₹500”.
• Network timeout happens → frontend retries.
• If API is not idempotent → two charges happen (₹1000 deducted).

• If API is idempotent (using unique transaction ID) → server checks:

  • First request processed ✅
  • Second request ignored, but response returned ✅

Result: Only one charge.

---

Summary

• Idempotency = multiple same requests → same effect.

• Helps in system design by:

  1. Avoiding duplicate operations (payments, bookings, orders).
  2. Making APIs reliable under retries.
  3. Ensuring consistency in distributed systems.

---

Most systems don’t start with idempotency in place until they scale or hit a real-world problem like duplicate payments, retries, or double bookings.

Let me explain why and how it’s used in practice:

---

1. Idempotency Keys (in payments & APIs)

• Not all systems generate idempotency keys.

• But payment gateways (Stripe, Razorpay, PayPal, etc.) force clients to provide one, because:

  • Network timeouts happen often.
  • Mobile apps can resend the same request if they didn’t get a response.
  • Without an idempotency key → customer gets charged multiple times.

✅ Example:

• Client sends POST /payments with {idempotency_key: "txn-12345"}.

• Server checks if "txn-12345" was already processed.

  • If yes → return the same response as before.
  • If no → process payment and store the result.

This way, retries are safe.

---

2. Database UPSERT (ON CONFLICT DO NOTHING / UPDATE)

• You’re right again — many teams just use INSERT and trust application logic.
• But in distributed systems, retries happen (e.g., Kafka consumer reprocessing an event).
• If you blindly INSERT, you’ll get duplicates.

✅ Example (Postgres):

INSERT INTO orders (order_id, user_id, amount) 
VALUES ('12345', 101, 500) 
ON CONFLICT (order_id) 
DO NOTHING;

• If the order already exists → DB ignores it.
• Ensures idempotency at the DB level, not just the application.

---

3. Why many teams skip it early

• Adds extra complexity (unique IDs, DB constraints, logic for deduplication).
• Small systems or internal tools can live without it.
• But once you’re handling payments, ticket bookings, inventory, or distributed retries, idempotency becomes non-negotiable.

---

4. Real-world example

• Without idempotency:

  • A user books the same flight twice because the app retried the request.
  • Two seats blocked → revenue and customer experience both suffer.

• With idempotency:

  • Retry is safe → only one booking created.

---

✅ In short:

• If your system never hit double-processing issues, you probably didn’t need idempotency yet.
• At scale, or in financial/critical transactions, idempotency becomes essential.

---