✅ 1️⃣ What Day 2 Was About
Day 2 topic: Idempotency
How to make sure the same request executed multiple times does NOT corrupt data
This sits between Day 1 (why systems fail) and Day 3 (race conditions).
✅ 2️⃣ What Was Covered in Day 2 (Explicitly)
✔ Meaning of “method called twice”
- User double-click
- Network retry
- Timeout retry
- Message redelivery
- Service-to-service retry
➡️ Same business operation runs more than once
✔ What Idempotency Means
Running the same operation 1 or N times produces the same final state
✔ Why Transactions Alone Are NOT Enough
- Transactions protect partial failure
- Idempotency protects duplicate execution
? Both are required
✔ Where Idempotency Must Be Enforced
✅ Database level
❌ Not only in code
❌ Not only in UI
✔ Core Idempotency Patterns
1️⃣ Idempotency Key
UNIQUE (request_id)
2️⃣ Business Uniqueness
UNIQUE (order_id)
3️⃣ State-based Update
UPDATE orders
SET status='PAID'
WHERE id=? AND status='CREATED';
✔ Idempotent Message Consumption
- Event redelivery is normal
- DB keeps processed event IDs
✔ What NOT to Do
- synchronized
- In-memory flags
- Redis-only
- UI prevention
✅ 3️⃣ Ultra-Compact Day 2 Notes (Standalone)
? DAY 2 — Idempotency (Quick Recall)
Definition
An operation that can be executed multiple times with the same result
Why needed
- Retries are normal
- Duplicates are unavoidable
How to enforce
- DB uniqueness constraint
- Idempotency key
- State-based updates
Golden rule
If an operation changes state, it must be idempotent
? How Day 1 → Day 2 → Day 3 Connect
| Day | Focus |
|---|---|
| Day 1 | Failures exist |
| Day 2 | Same request may repeat |
| Day 3 | Different requests may collide |
Together they answer:
“What if it runs twice?”
“What if it runs at the same time?”
