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.