/System Design /Idempotency ← All Designs
🔑

Idempotency

Make operations safe to retry without unintended side effects

PHASE 3 SYSTEM DESIGN INTERACTIVE
✗ Without Idempotency Key
Incoming Requests
SERVER — processes every request
🗄️ DATABASE 0 records
Operations created: 0
✓ With Idempotency Key
Incoming Requests (keyed)
🗃️ IDEMPOTENCY STORE (key → cached response)
SERVER — checks key before processing
🗄️ DATABASE 0 records
Operations created: 0
📋 Request Log
Send a request to see the log
0
Requests Sent
0
Ops (no key)
0
Duplicates Prevented
$0
Money Saved
Idempotency Key Flow
Client sends
POST /payment
Idempotency-Key: UUID
→
Server checks
idempotency
store
→ KEY SEEN
→
Return cached
response 200
(no re-execute)
→ KEY NEW
→
Process + store
result in
idempotency DB
📖 How Idempotency Works

An idempotency key is a unique client-generated ID (UUID) attached to each request. The server stores the key + response. On retry, it returns the stored response without re-executing the operation. This makes retry-safe APIs possible.

MUST be idempotent:
💳 Payment processing 📧 Email / notification sending 📦 Order creation 💾 DB writes with side effects
Naturally idempotent:
GET — read-only, no state change PUT — replace (same result each time) DELETE — deleting twice = deleted POST — NOT idempotent (must add key)
Key Concepts
🎯 When to Use
Any operation with side effects that clients may retry — payment processing, notifications, inventory changes, order creation at scale.
⚖️ Trade-offs
Need to store idempotency keys with TTL (usually 24h); key must be client-generated UUID; slight storage overhead; add clearly to API docs.
💡 Interview Tip
"Stripe and PayPal both require Idempotency-Key headers. The key should be a UUID generated client-side before the first attempt, then reused on all retries."