Idempotency for safe retries in HLD - Practice Problems & Coding Challenges

Challenge - 5 Problems

🧠 Conceptual

intermediate

Understanding Idempotency in API Design

Which statement best describes the purpose of idempotency in API requests?

A Ensures that multiple identical requests have the same effect as a single request.

B Guarantees that every request is processed exactly once without any retries.

C Allows requests to be processed in any order without affecting the outcome.

D Prevents any request from being retried automatically by clients.

💡 Hint

Think about what happens when a client sends the same request multiple times due to network issues.

Idempotency means that repeating the same request multiple times results in the same state as making it once. This helps safe retries.

❓ Architecture

intermediate

Designing Idempotent Payment API

You are designing a payment API that must support safe retries. Which design choice best supports idempotency?

A Reject any repeated payment requests from the same client IP address within a short time window.

B Process every payment request immediately without checking for duplicates to ensure speed.

C Require clients to send a unique transaction ID with each payment request and store processed IDs to avoid duplicates.

D Allow clients to retry without any unique identifiers and rely on server timestamps to detect duplicates.

💡 Hint

Consider how the server can recognize repeated requests safely.

Using a unique transaction ID lets the server detect and ignore duplicate requests, ensuring idempotency.

❓ scaling

advanced

Scaling Idempotency Key Storage

Your system uses idempotency keys to avoid duplicate processing. As traffic grows, what is the best approach to scale idempotency key storage?

A Use a distributed cache with expiration to store idempotency keys and their results for a limited time.

B Keep idempotency keys only in application memory to reduce latency, without persistence.

C Store all idempotency keys indefinitely in a single relational database table without indexing.

D Require clients to resend idempotency keys if the server loses them due to scaling.

💡 Hint

Think about balancing fast access and storage limits as traffic increases.

A distributed cache with expiration provides fast access and limits storage size, helping scale idempotency key management.

❓ tradeoff

advanced

Tradeoffs in Idempotency Key Expiration

What is the main tradeoff when setting a short expiration time for stored idempotency keys?

A Short expiration increases storage needs and prevents any duplicate processing.

B Short expiration reduces storage but risks processing duplicates if retries happen after expiration.

C Short expiration guarantees no duplicates but increases latency for all requests.

D Short expiration allows clients to reuse keys indefinitely without server checks.

💡 Hint

Consider what happens if a retry arrives after the key is removed.

Short expiration limits storage but may cause duplicates if retries come after keys expire, risking repeated processing.

❓ estimation

expert

Estimating Idempotency Key Storage Capacity

Your API receives 10,000 requests per second, each with a unique idempotency key stored for 24 hours. Each key and result entry uses 1 KB of storage. What is the approximate storage needed to hold all keys for 24 hours?

A 8640 GB

B 86.4 GB

C 8.64 TB

D 864 GB

💡 Hint

Calculate total requests in 24 hours and multiply by storage per key.

10,000 requests/sec * 3600 sec/hr * 24 hr = 864 million keys. 864 million KB = 864 GB.

Practice

1. What is the main purpose of idempotency in system design for safe retries?

easy

A. To increase the number of retries allowed

B. To ensure repeated requests produce the same result without side effects

C. To speed up the processing of new requests

D. To encrypt data during transmission

Solution

1. Step 1: Understand idempotency concept

   Idempotency means that making the same request multiple times results in the same outcome without causing additional changes.

2. Step 2: Identify the purpose in retries

   In safe retries, idempotency prevents duplicate processing and side effects by returning the same result for repeated requests.

3. Final Answer:

   To ensure repeated requests produce the same result without side effects -> Option B

4. Quick Check:

   Idempotency = Same result, no side effects [OK]

Hint: Idempotency means retrying won't change the outcome [OK]

Common Mistakes:

• Confusing idempotency with performance optimization
• Thinking idempotency increases retry limits
• Assuming idempotency encrypts data

2. Which of the following is the correct way to implement idempotency in an API request?

easy

A. Retry the request without any tracking

B. Encrypt the request payload for security

C. Ignore request IDs and process every request as new

D. Use a unique request ID to detect duplicates and avoid reprocessing

Solution

1. Step 1: Identify idempotency implementation method

   Idempotency requires tracking requests to detect duplicates, typically using a unique request ID.

2. Step 2: Evaluate options

   Only using a unique request ID allows the system to recognize repeated requests and avoid reprocessing.

3. Final Answer:

   Use a unique request ID to detect duplicates and avoid reprocessing -> Option D

4. Quick Check:

   Unique request ID = Idempotency key [OK]

Hint: Unique request ID prevents duplicate processing [OK]

Common Mistakes:

• Retrying blindly without tracking
• Ignoring request IDs
• Confusing encryption with idempotency

3. Consider a system that stores results of processed requests keyed by a unique request ID. If a client sends the same request twice with the same ID, what will the system return on the second request?

medium

A. A new result generated by reprocessing

B. An error indicating duplicate request

C. The original result from the first request

D. A timeout response

Solution

1. Step 1: Understand stored result usage

   The system caches the result of the first request using the unique request ID.

2. Step 2: Determine response for repeated request

   When the same request ID is received again, the system returns the cached original result to maintain idempotency.

3. Final Answer:

   The original result from the first request -> Option C

4. Quick Check:

   Repeated request returns cached result [OK]

Hint: Same ID returns cached result, not reprocessed output [OK]

Common Mistakes:

• Expecting an error on duplicate requests
• Assuming reprocessing happens every time
• Confusing timeout with duplicate handling

4. A developer implemented idempotency by storing request IDs but forgot to store the response results. What problem will this cause on retries?

medium

A. The system will reprocess the request causing side effects

B. The system will return the original result correctly

C. The system will reject all requests

D. The system will crash due to missing data

Solution

1. Step 1: Analyze missing response storage impact

   Without storing the response, the system cannot return the original result on retries.

2. Step 2: Identify retry behavior

   Since the system lacks the cached result, it reprocesses the request, causing potential side effects and breaking idempotency.

3. Final Answer:

   The system will reprocess the request causing side effects -> Option A

4. Quick Check:

   Missing response storage = Reprocessing on retry [OK]

Hint: Store both request ID and response to avoid reprocessing [OK]

Common Mistakes:

• Assuming storing request ID alone is enough
• Expecting system to reject retries automatically
• Thinking system crashes without response data

5. You design a payment system that must be idempotent to handle retries safely. Which combination of techniques best ensures idempotency and prevents duplicate charges?

hard

A. Use unique request IDs, store payment results, and check before processing

B. Allow retries without tracking, rely on client to avoid duplicates

C. Encrypt payment data and retry immediately on failure

D. Process every request independently to ensure payment completion

Solution

1. Step 1: Identify idempotency requirements for payments

   Payments must not be charged multiple times on retries, so tracking requests and results is essential.

2. Step 2: Evaluate techniques for safe retries

   Using unique request IDs to detect duplicates, storing results to return on retries, and checking before processing prevents duplicate charges.

3. Final Answer:

   Use unique request IDs, store payment results, and check before processing -> Option A

4. Quick Check:

   Unique ID + stored result = Safe payment retries [OK]

Hint: Combine unique IDs and result storage for safe retries [OK]

Common Mistakes:

• Relying on client to avoid duplicates
• Ignoring result storage
• Processing every request without checks