Loading pattern...

What is Idempotency?

Idempotency means an operation can be called multiple times with the same result. Charging a credit card is NOT idempotent (charge twice = double charge). Creating a user with "create if not exists" IS idempotent (call twice = one user). Critical for payments, APIs, and any operation that could be accidentally retried. Implement with idempotency keys—client sends unique ID, server checks "already processed this ID?"

When Should You Use This?

Make operations idempotent when they involve money (payments, refunds), when network failures could cause retries, when users might click "submit" multiple times, or in distributed systems where messages might be delivered twice. All payment APIs (Stripe, PayPal) require idempotency keys. Essential for reliability, prevents duplicate charges/orders/emails.

Common Mistakes to Avoid

  • No idempotency for payments—user charged twice when network fails
  • Wrong scope—idempotency key should be unique per operation, not global
  • Not storing keys—key expires too soon, retry happens after expiry
  • Idempotency for reads—GET requests are naturally idempotent, don't need keys
  • No timeout—idempotency key locked forever if original request never completes

Real-World Examples

  • Stripe—Requires idempotency keys for all payment API calls
  • E-commerce—Order submission with idempotency prevents duplicate orders
  • Banking—Transfers are idempotent, same request twice doesn't transfer twice
  • Email services—Idempotency ensures same email doesn't send twice on retry

Category

System Design Patterns

Tags

idempotencyapi-designreliabilitypaymentssystem-design

Permalink