Design a Cross-Border Fulfillment System

Problem statement

Design a cross-border fulfillment system that takes an order placed by a customer in one country, decides where it should ship from, computes the landed cost (goods + shipping + duties + taxes), generates legally correct export and customs documentation, selects a carrier that can legally and economically move the parcel across the border, tracks it through customs clearance, and handles returns or refunds when the shipment fails. The system must work across many origin countries, many destination countries, many carriers, and many tax regimes at once.

This is not a domestic e-commerce backend with a currency converter bolted on. A domestic order can retry a failed label purchase. A cross-border order that clears customs with an incorrect HS code, an undervalued commercial invoice, or a missing import license creates a legal liability, a seized parcel, a fine for the importer of record, and a customer who never receives the goods. Therefore the design separates order progress from compliance correctness. Order progress is an eventually progressing workflow: created, promised, picked, packed, handed to carrier, in transit, in customs, delivered. Compliance correctness is an invariant: the system may only tender a parcel to a carrier when the documentation, valuation, classification, and destination-country permissions have been validated against the active rule set for that specific origin-destination pair.

Why the problem is distinctive

A food-delivery or ride-sharing backend mostly coordinates within one legal and currency space. Cross-border fulfillment coordinates across dozens of them simultaneously, and the rules are asymmetric: the export rules of the origin country, the import rules of the destination country, the transit rules of any country the parcel passes through, and the carrier's own acceptability rules all apply at once. The problem requires duty calculation per destination, customs paperwork generation with HS codes and commercial invoices, region-specific carrier selection, and cross-border returns or refunds, all under high reliability, regulatory compliance, scale, and localization requirements.

The public record shows this category is operationally real and large. Shopify reported peak checkout throughput of 44,745 orders per minute during Black Friday Cyber Monday 2023 and more than 9 billion dollars in merchant GMV across that weekend, a large share of which is international. Zalando ended 2023 serving roughly 50 million active customers across about 25 European markets with localized pricing and VAT. Flexport, a digital freight forwarder, reached a reported 8 billion dollar valuation in 2022 by turning customs brokerage and freight into software. These are cited public figures used for context; every uncited scale or SLO in this answer is an explicit design assumption.

The four architectural planes

1. Commerce plane: catalog, pricing, landed-cost promise, checkout, payment, order intake.
2. Compliance plane: HS classification, duty and tax rules, restricted-party and export-control screening, document generation, importer-of-record resolution.
3. Fulfillment plane: inventory placement, sourcing decision, pick-pack, carrier selection, label and manifest generation, handoff.
4. Tracking and recovery plane: carrier tracking ingestion, customs milestone events, exception handling, returns, refunds, and compensation.

A strong interview answer keeps these planes separate. It lets the commerce plane degrade (slower landed-cost quotes) without weakening the compliance plane (never ship with unvalidated documents), and it lets the tracking plane lag without falsely advancing the order state. The core discipline is that a parcel crosses a legal boundary only after the compliance plane has produced a validated, versioned, auditable permission to do so.