Module 6 - Distributed Systems

Idempotency

Same request, same result-no matter how many times you send it.

1The Elevator Button Analogy

Simple Analogy

Press the elevator button once or 10 times-the result is the same: elevator comes. That's idempotency. Contrast with a vending machine: each button press dispenses a drink. NOT idempotent.

An operation is idempotent if executing it multiple times has the same effect as executing it once. Critical for handling retries in distributed systems.

2HTTP Methods

Method	Idempotent?	Explanation
GET	Yes	Reading data doesn't change state
PUT	Yes	Setting to same value repeatedly = same result
DELETE	Yes	Deleting already-deleted = same (gone)
POST	No	Creates new resource each time
PATCH	Depends	"increment by 1" is not; "set to 5" is

3Real-World Dry Run: Payment Processing

Scenario: User clicks "Pay $100" but network is slow

User clicks Pay

Request sent with idempotency_key: 'abc123'

Network timeout

User doesn't see response, clicks Pay again

Second request sent

Same idempotency_key: 'abc123'

Server receives both

First request is processing, second arrives

Without Idempotency

Both requests process. User charged $200. Support ticket incoming.

With Idempotency Key

Server sees same key, returns cached result. User charged $100 once.

4Implementation Patterns

Idempotency Key

Client sends unique key (UUID) with request. Server stores key + result. Duplicate key returns cached result.

Example: Stripe API: X-Idempotency-Key header

Conditional Updates

Use IF-MATCH with ETag or version number. Update only if version matches.

Example: PUT /user/123 IF-MATCH: v5

Database Constraints

Unique constraint on transaction_id prevents duplicate inserts.

Example: UNIQUE INDEX on (user_id, transaction_id)

Deduplication Table

Store processed request IDs. Check before processing new requests.

Example: processed_requests table with TTL

5Common Pitfalls

Generating Key Server-Side

Key must come from client. Server-generated keys can't deduplicate retries.

Key Expiration

Keys should expire (e.g., 24h). Forever storage grows unbounded.

Side Effects

Sending emails must also be idempotent-track what was sent.

Partial Failures

If DB write succeeds but cache fails, retry might skip DB.

6Key Takeaways

1Idempotent: same request, same result, no matter how many times

2Essential for safe retries in distributed systems

3Use idempotency keys (client-generated UUIDs)

4GET, PUT, DELETE are naturally idempotent; POST is not

5Store key + result for TTL, return cached result on duplicate

?Quiz

1. POST /orders creates order. User retries. What happens without idempotency?

2. Who should generate the idempotency key?