Design Idempotent Request Replay

1. Problem Statement

2. Architecture Discussion Map

Use this as one discussion aid, not a single correct answer. Your design should follow from the requirements, scale, and trade-offs you establish.

graph LR
    A["Design Idempotent Request Replay"]
    A --> F1["Canonical request identity"]
    A --> F2["Durable idempotency records"]
    A --> F3["Concurrent duplicate handling"]
    A --> F4["Crash recovery and replay"]
    A --> F5["Retention and observability"]

3. Key Focus Areas

• 1
  Canonical request identity
• 2
  Durable idempotency records
• 3
  Concurrent duplicate handling
• 4
  Crash recovery and replay
• 5
  Retention and observability

4. What the Interviewer Looks For

The interviewer probes these areas, and the report grades the interview against them.

• Logical identity and canonicalization
• Durable idempotency record and atomic claim
• Crash recovery and exactly-once effects
• Retention, capacity, and observability
• Step-by-step processing logic and test cases

5. What Strong Candidates Should Demonstrate

• Define logical request identity independently from transport retries.
• Choose a deduplication retention policy and persistence boundary.
• Explain exactly-once effects using idempotent state transitions.