Why is DELETE /users/42 considered idempotent?

Idempotency means f(f(x)) = f(x). Deleting a user twice leaves them deleted; the second call has no effect.

Which operation is non-idempotent by default and requires protection?

POST creates new resources. Each POST /orders creates a different order, making it non-idempotent without explicit deduplication.

In the duplicate charge scenario, when does the duplicate occur?

Client has no confirmation response, assumes failure, and retries. Server has already processed the first request.

What is a race condition in retry handling?

Without locking, both threads see 'not found' in the CHECK step, then both proceed to PROCESS, creating duplicates.

Which of these three network failure modes causes duplicates without idempotency?

In all three cases, client lacks confirmation and retries. Without idempotency, the server reprocesses.

Why must the client generate the idempotency key instead of the server?

Client generates the key BEFORE sending. If request fails, client retries with same key. If server generated it, failed request = no key for retry.

What is the collision probability for UUID v4?

UUID v4 is 128 bits with 6 bits of version/variant overhead, leaving ~122 bits of randomness: 2^122 possible values.

Which idempotency key strategy is human-readable but risks collision?

Semantic keys are self-describing but collision risk depends on careful field selection. Hash-based is deterministic but opaque.

In the Python code example, what critical property must the idempotency key have?

The key is stored BEFORE sending. On timeout/retry, the client uses the SAME key. This allows server to detect duplicates.

What is the purpose of the LOCK step in server-side idempotency?

Lock ensures only one thread processes a key. Without it, two threads can both pass CHECK and both PROCESS, causing duplicates.

What should the server return if the idempotency key is found in the CHECK step?

If the key exists, we have the result from the first request. Return it immediately to the client.

In the CHECK → LOCK → PROCESS → CACHE pattern, why does the second thread wait for the lock if it sees 'not found'?

Between CHECK and LOCK, the first thread may have acquired the lock. The second must wait for lock, then CHECK again in case result was cached.

What happens if the PROCESS step fails (e.g., payment declined)?

Failed results should not be cached (or cached with different handling). Retry should see 'not found', reprocess, and may succeed.

Which storage systems can implement idempotency locks?

Any system supporting atomic check-and-set or distributed locks can work: Redis, SQL databases, Redlock, Zookeeper, etc.

What is the risk if TTL is set too short?

If record is deleted before the last retry arrives, server sees 'not found' and processes again, duplicating the result.

What is the risk if TTL is set too long?

Long TTL means records persist indefinitely. With millions of requests, memory grows without bound.

For a payment system, what is a reasonable TTL for idempotency records?

Payments are high-stakes; users may retry manually for days. 24-48 hours balances safety and storage cost.

Why might network operations have a shorter TTL than financial operations?

Network timeouts trigger quick automatic retries (seconds/minutes). Payments are high-stakes; users retry manually for days.

How should TTL be chosen relative to the retry window?

TTL must outlast the maximum retry window. If max retry is 24h, TTL should be 24h+ to catch all retries.

Which endpoints MUST be idempotent?

Payments and refunds are critical financial operations. Double charge = direct financial loss and trust violation.

Why should notification endpoints be idempotent?

Duplicate notifications annoy users and waste delivery cost. Should be idempotent but lower priority than payments.

What is the risk of non-idempotent order creation?

Duplicate orders have immediate business impact: wrong items shipped, inventory chaos, fulfillment cost.

Why might appointment waitlist endpoints benefit from idempotency?

Duplicate enrollment = same user appears twice in waitlist. When slot opens, they receive two notifications or are booked twice.

Which statement is correct about idempotency in async operations?

Async jobs can also fail and be retried. Use idempotency key to deduplicate job queue entries.

What is the primary challenge in an arcade payment system that requires idempotency?

Arcade environments have unstable networks and hardware may retransmit the same request multiple times on timeout.

What should the arcade terminal idempotency key include?

Combination of terminal ID (which arcade machine), transaction ID (which payment), and timestamp (when) ensures uniqueness.

Why must the mall kiosk idempotency key include store ID?

Multiple stores may have same cart IDs. Store ID scopes the idempotency key to prevent cross-store conflicts.

What is the purpose of marking 'receipt_already_printed' in the cached response?

Receipt printer has side effect. On cached response, kiosk must NOT reprint. Flag tells kiosk the receipt already printed.

Why does the mall kiosk use timestamp rounded to minute in the idempotency key?

Within a minute, retries use same key (deduplication). After minute, new transaction = new minute bucket = new key (no collision).

What is 'two-layer idempotency' in the appointment waitlist system?

Join request idempotency prevents duplicate enrollment. Notification send idempotency prevents duplicate alerts.

Why does the waitlist join endpoint also query the database to check for existing enrollment?

Database query checking 'user already on waitlist' provides secondary safety layer if HTTP idempotency fails.

In the appointment system, what happens if a slot opens and multiple workers try to notify the same waitlist user?

Notification send uses its own idempotency key (user + slot + event). First send is cached; retries return cached result.

Idempotency — System Design Concept

Q: Which of the following HTTP operations is naturally idempotent?

GET is idempotent because reading does not modify state. POST operations create new resources and are non-idempotent by default.

🍪 TechCookies

Free

Loading system design concepts and challenges…

📚IdempotencyFree

10 sections

~28 min total

33 quick quizzes

3 SD challenges linked

0 of 10 done·~27 min left

Concepts›Idempotency›What Is Idempotency?

0 / 10

10 sections~28 min

What Is Idempotency?

An operation is idempotent if applying it multiple times produces the same result as applying it once.

ReadQuiz

~3 min

⋯

Why Retries Cause Duplicates Without Idempotency

Networks, timeouts, and crashes can cause clients to retry requests that were already processed, creating duplicates.

ReadQuizCode

~3 min

⋯

Idempotency Keys: Client-Generated UUIDs

Client generates a unique UUID before sending a request and reuses it on all retry attempts.

ReadQuizCode

~3 min

⋯

Server-Side Implementation: Check → Lock → Process → Cache

Four-step pattern: check if key exists, acquire lock, execute business logic, store result with TTL.

ReadQuizCode

~3 min

⋯

TTL Design for Idempotency Stores

Set time-to-live carefully: too short causes duplicates, too long wastes storage.

ReadQuizCode

~3 min

⋯

Where to Apply Idempotency

Payments, refunds, orders, notifications, and appointments always require idempotency protection.

ReadQuizCode

~3 min

⋯

System Design Deep Dive: Arcade Payment System

Apply idempotency to arcade card reader payments handling unstable WiFi and hardware retransmissions.

ReadQuizCode

~3 min

⋯

System Design Deep Dive: Mall Kiosk Payment

Multi-store kiosk payments with receipt deduplication and store-specific idempotency keys.

ReadQuizCode

~3 min

⋯

System Design Deep Dive: Appointment Waitlist

Two-layer idempotency for waitlist joins and notification sends to prevent duplicate entries and alerts.

ReadQuizCode

~3 min

⋯

Practice test

33 questions

~11 min

Section 1 of 10ReadQuick quiz

What Is Idempotency?

An operation is idempotent if applying it multiple times produces the same result as applying it once.

~3 min read

3 quick quizzes

The word "idempotent" comes from mathematics. An operation is idempotent if applying it multiple times produces the same result as applying it once.

f(f(x)) = f(x)

In software:

Operation	Idempotent?	Why
`GET /users/42`	✅ Yes	Reading does not change state
`DELETE /users/42`	✅ Yes	Deleting twice = same end state (user is gone)
`PUT /users/42 {name: "Alice"}`	✅ Yes	Setting a value twice = same result
`POST /orders`	❌ No (by default)	Each call creates a NEW order
`POST /payments`	❌ No (by default)	Each call charges the customer again

The goal of idempotency design is to make non-idempotent operations safe to retry.

Quick check 1/3

Which of the following HTTP operations is naturally idempotent?

AGET /users/42

BPOST /orders

CPOST /payments

DPOST /notifications

Answer the quiz to continue

Notes

🔍

Loading…