Flipkart Marketplace Platform  ·  View 16 of 25  ·  5 · Runtime

Order Lifecycle and Failure Paths

The state machine the Order service owns, including every way out of it.

Editable source SVG draw.io All views
Capture CREATED PAYMENT_PENDING Authorise AUTHORISED PAYMENT_FAILED Commit CONFIRMED stock committed CANCELLED by buyer Prepare PACKED SELLER_CANCELLED SLA penalty Move SHIPPED OUT_FOR_DELIVERY RTO undeliverable Close DELIVERED RETURN_REQUESTED REFUNDED declined or timeout buyer cancels no stock at pick 3 attempts within window graded and accepted auto refund Order Lifecycle — States and Every Way Out Application we own Decision point Risk / gap Opportunity failure / alternate synchronous The Order service owns this machine and nothing else writes to it. Every red transition emits a compensating event; refunds and inventory releases are Temporal sagas, not in-line calls. v 1.0 · owner Commerce Engineering · date 2026-09

Decisions

  • The Order service is the sole writer of order state; every other system reacts to its events
  • Every red transition emits a compensating event rather than mutating another service directly
  • Refunds, inventory releases and seller penalties are sagas with their own retries and their own visibility

Why the failure states are drawn

  • SELLER_CANCELLED after CONFIRMED is the marketplace-specific failure a single-vendor design never has, and it drives seller quality scoring
  • RTO is expensive and invisible in most designs; drawing it makes the reverse-logistics cost a first-class concern
  • PAYMENT_FAILED and CANCELLED look similar to a customer and completely different to a ledger

Deliberately omitted

  • Partial cancellations and split shipments, which multiply the state count without changing the shape
  • Exchange, which is modelled as a return plus a new order
  • Timeout durations per transition, which live in the runbook