Design Returns Processing

Problem Statement & Context

Returns processing is not a back-office afterthought — it is simultaneously a customer-trust surface and a P&L lever, which is why a serious design treats it as a first-class system. A mid-market retailer sees 8 to 12% of gross merchandise value flow back through returns, and that rate can double for the 30 days after the holidays. Amazon, Zappos, and Nordstrom built brand reputations partly on frictionless returns, so the architecture must optimize three things that pull against each other: speed (refund the customer fast), auditability (finance must reconcile every dollar), and fraud resistance (returns are heavily exploited).

The defining tension is that money moves before the physical goods are verified. A customer expects a fast refund, but the warehouse has not yet inspected the returned item — so the system must decide how much trust to extend (instant refund versus refund-after-inspection) and reconcile the two when the item finally arrives and is graded. That trust decision, made per customer and per return, is the heart of the design and the place fraud lives.

The system is fundamentally a workflow with financial controls, not a CRUD service. A return moves through a state machine — requested, approved, label issued, in transit, received, inspected, refunded — with money-moving steps that must be exactly-once and auditable. The return_id is the aggregate root, order data is snapshotted (never a live join on the hot path), and every state change is an append-only event, so the whole lifecycle is reconstructable for disputes and chargebacks months later.

Scale is spiky and seasonal. Assume 5 million orders a day at a 10% return rate (500k return requests/day), tripling to 1.5M/day in the post-holiday January spike, with the warehouse scanning ~2M package events a day at peak. The numbers are moderate, but the difficulty — as with the other money-adjacent commerce designs — is correctness under retries and fraud pressure, not raw throughput.