APIs define operations, identity, errors and retry behavior. A client needs to distinguish failure, uncertainty and successful completion.
Before you start
You should understand API requests, storage and basic capacity estimates. Begin with a concrete user action and its correctness requirement. Draw data flow and failure boundaries before selecting infrastructure; a technology name by itself does not explain why a design meets the requirement.
The practical goal is to reason through this situation: An asynchronous export returns an operation ID with a status resource. Read the walkthrough first, then try the interview exercise before opening its answer. The important part is explaining the decision and its consequences, rather than remembering a definition alone.
Step-by-step walkthrough
Step 1: Define operation identity
Creation needs a way to recognize one logical request.
Step 2: Distinguish acceptance and completion
An accepted export can still be pending or fail later.
Step 3: Provide outcome retrieval
Clients need to recover after a response is lost.
Worked scenario
An asynchronous export returns an operation ID with a status resource.
An export API returns an operation ID and status URL. The client polls pending, completed or failed state and can retrieve the result. If the create response is lost, a stable idempotency key identifies the original export instead of silently creating another job on each retry.
Common mistake
An accepted response does not mean the requested work has finished.
Verify the behavior
Test lost response, repeated creation and failed asynchronous completion.
Interview exercise
Design retryable creation.
Answer and reasoning
Use stable operation identity, define idempotency and provide a way to retrieve the outcome after a lost response.
Continue learning
Compare the scenario with the System Design interview questions and test your understanding with the System Design MCQs. For terminology and implementation details, consult the reference material.