Api Design medium
Stripe's API requires an Idempotency-Key header for POST requests. A client sends the same key twice. What should the server do on the second request?
- A Process the second request as a new transaction, as idempotency keys are intended for diagnostic tracing rather than functional deduplication.
- B Return the cached response from the successful first request immediately, ensuring the underlying state-changing operation is only executed once.
- C Return a 409 Conflict status code to inform the client that a resource with the same identifier or key already exists in the system.
- D Delete the existing record associated with that key and re-initialize the operation to ensure the final state reflects the latest request parameters.
Answer: B. Return the cached response from the successful first request immediately, ensuring the underlying state-changing operation is only executed once.
Idempotency ensures that performing the same operation multiple times yields the same result as performing it once. When a client sends a request with an **Idempotency-Key**, the server caches the initial response. If the client retries with the same key (e.g., after a network timeout), the server returns the cached response instead of processing the transaction again, preventing duplicate charges.
One system design question a day, with spaced repetition so the ones you miss come back.
Get the appRelated questions
- You're designing a REST API for a blog. Which endpoint best represents 'get all comments for post 123'?
- A client wants to update only the 'status' field of an order, leaving other fields unchanged. Which HTTP method is most appropriate?
- A client calls POST /users with valid data, and the user is created. What status code should the server return?
- A client retries a failed 'POST /payments' request due to network timeout. The server receives the request twice. Without idempotency handling, what can happen?
- An API returns 10,000 products. Returning all in one response is impractical. Which pagination approach is simple and stateless?
- Your API serves both mobile apps and third-party integrations. Which authentication method is most appropriate?