Flipkart Marketplace Platform · View 14 of 25 · 5 · Runtime
Decisions
- Stock is reserved before payment is requested, with a 900-second TTL that expires on its own
- One idempotency key travels from checkout intent through authorisation, webhook and order creation
- Order creation is a Temporal saga: if confirmation fails after capture, the compensation is a refund, not a retry loop
Failure handling
- No webhook within 90 seconds triggers a status poll, then a void — the platform never waits indefinitely on a rail
- A duplicate webhook is deduplicated on the PSP reference before it reaches the order service
- Every abandoned path releases the reservation explicitly; expiry is the backstop, not the mechanism
Targets
- Checkout p95 500 ms excluding the time the customer spends in their bank app
- Reservation call p99 under 20 ms — it is a Redis compare-and-set, not a database transaction
- Zero tolerance on oversell and on double capture; both are alerted, not sampled