Problem Statement: Design Dropshipping Platform
Problem Statement: Design Dropshipping Platform — dropshipping system design interview depth
Problem Statement: Design Dropshipping Platform
A dropshipping platform is an orchestration and synchronization layer for a three-sided marketplace: it connects merchants (who curate storefronts), end customers (who buy), and external suppliers (who hold the actual inventory and ship). The defining architectural fact — and what makes it unlike a classic retail OMS — is that stock truth lives at the suppliers, not in your database. You never hold inventory; you orchestrate. Shopify with Oberlo, Spocket, and AliExpress-backed stores all live on this premise.
The core flow: a merchant publishes curated SKUs (each mapping to a supplier's product) on their storefront; when a buyer checks out, the platform routes a purchase order to the winning supplier, forwards the payment splits (supplier COGS, merchant margin, platform fee), and streams tracking back to the buyer. Your system's job is to make three parties who do not trust each other's latency or availability behave like one coherent store.
The interviewer is listening for whether you grasp that the supplier is an unreliable, rate-limited, eventually-consistent dependency — not a synchronous extension of your cart. The single biggest mistake is treating a supplier API call as part of the checkout request. The failure that defines the design: checkout calls the supplier's create-order API synchronously, AliExpress rate-limits you at 100 req/s, and now checkout blocks for 8 seconds and times out during a flash sale. The correct design captures payment and a virtual hold synchronously (fast, CP), then routes the PO to the supplier asynchronously within ~30 seconds — decoupling the buyer's sub-second checkout from the supplier's slow, flaky API.
Key Highlights
- •Dropshipping is an orchestration/sync layer for a three-sided marketplace — stock truth lives at suppliers, not your DB
- •Core flow: merchant curates -> buyer checks out -> route PO to winning supplier -> split payment -> stream tracking back
- •The supplier is an unreliable, rate-limited, eventually-consistent dependency — never a synchronous extension of the cart
- •Defining failure: a synchronous supplier call in checkout blocks 8s under a 100 req/s cap — capture sync, route async (~30s)
Section Rescue Kit
Buzzwords to use:
Safe statements:
- "For Problem Statement: Design Dropshipping Platform, I'll separate checkout latency from async supplier routing."
- "I'll cite supplier rate limits before promising real-time stock everywhere."