🔒 Paid

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