Patterns

35 items

System Design Pattern

Reliabilityidempotencyidempotency-keysafe-retrydeduplicationexactly-onceintermediate

Idempotency Pattern

Making operations safe to retry multiple times

Used in: Payment Systems, APIs, Message Processing|20 min read

Summary

Idempotency ensures that performing an operation multiple times has the same effect as performing it once. In distributed systems, requests can be retried due to timeouts, network issues, or client bugs. Without idempotency, retries cause duplicate actions (double charges, duplicate orders). Implementing idempotency requires unique request IDs, storing operation results, and returning cached results on duplicates. This pattern is essential for any operation with side effects - payments, orders, resource creation. Stripe, AWS, and all payment systems use idempotency keys.

Key Takeaways

Retries Are Inevitable

Networks fail, timeouts happen, clients retry. Without idempotency, every retry risks duplicate side effects. Plan for retries from the start.

Idempotency Key Pattern

Client generates unique key, includes in request. Server checks if key was seen before. If yes, return cached result. If no, process and cache.

Natural vs Artificial Idempotency

Some operations are naturally idempotent (set value to X). Others need artificial idempotency (add Y requires tracking to prevent double-add).

Scenario without idempotency:

Client sends payment request: "Charge $100"
Server processes, charges card
Response lost due to network timeout
Client retries: "Charge $100"
Server charges card again
Customer charged $200!

With idempotency:

Client sends: "Charge $100, key=abc123"
Server processes, stores result with key abc123
Response lost
Client retries: "Charge $100, key=abc123"
Server finds key abc123, returns cached result
Customer charged $100 correctly

Summary

Key Takeaways

Retries Are Inevitable

Networks fail, timeouts happen, clients retry. Without idempotency, every retry risks duplicate side effects. Plan for retries from the start.

Idempotency Key Pattern

Client generates unique key, includes in request. Server checks if key was seen before. If yes, return cached result. If no, process and cache.

Natural vs Artificial Idempotency

Some operations are naturally idempotent (set value to X). Others need artificial idempotency (add Y requires tracking to prevent double-add).

Storage Requirements

Must store idempotency keys and results. TTL to prevent unbounded growth. Usually 24-48 hours sufficient.

Scope of Idempotency

Key should scope to specific operation AND user. Same key for different users should be independent.

Concurrent Requests

Two simultaneous requests with same key must not both execute. Use locking or compare-and-swap.

Pattern Details

Scenario without idempotency:

Client sends payment request: "Charge $100"
Server processes, charges card
Response lost due to network timeout
Client retries: "Charge $100"
Server charges card again
Customer charged $200!

With idempotency:

Client sends: "Charge $100, key=abc123"
Server processes, stores result with key abc123
Response lost
Client retries: "Charge $100, key=abc123"
Server finds key abc123, returns cached result
Customer charged $100 correctly

Trade-offs

Aspect	Advantage	Disadvantage

Patterns

Horizontal Scaling Pattern

Retry with Backoff Pattern

Replication Pattern

Caching Strategies Pattern

Persistent Connections Pattern

Load Balancing Pattern

Fan-out Pattern

Fan-in Pattern

Circuit Breaker Pattern

Eventual Consistency Pattern

Queue-based Load Leveling Pattern

Bloom Filters Pattern

Time-Series Storage Pattern

Bulkhead Pattern

Batch Processing Pattern

Write-Ahead Log Pattern

API Gateway Pattern

Backend for Frontend Pattern

Sidecar Pattern