Duplicate Request Processing
A downstream dependency has slowed down, and order-service response times are rising. Clients that do not hear back before their own timeout has no way to know whether their first request actually went through, and both the client and the API gateway retry independently. An order's side effect (the charge it creates) must be applied at most once per logical request, regardless of how many times that request is retried along the way — a request that executes its side effect twice is a correctness incident, not a cosmetic one, even if every retry eventually returns a successful response. Diagnose why orders are being duplicated and bring the system to a state that is genuinely safe to hand back, not merely fast.
- Difficulty
- Staff
- Expected Time
- ~20 min
- Category
- Distributed Systems
Skills
- Distinguishing apparent request success from correctness guarantees
- Recognizing when a retry mitigation increases duplicate side effects
- Reasoning about client-side timeout ambiguity and acknowledgement uncertainty
- Evaluating idempotency-key enforcement and atomic transaction tradeoffs
System Architecture
- Client
- API Gateway
- Order Service
- Database / Side Effect
This is a Pro scenario. Upgrade to Pro to unlock it.
Upgrade to ProBack to Incidents