How the interviewer opens it
“Design a platform where merchants create and run independent online stores. Merchants can customize their storefronts, and traffic can rise without warning.”
The prompt is vague on purpose. The first minutes are for you. Reduce the prompt to the core features and agree on the numbers before you draw.
What to clarify first
- Store and catalog scale
- Read and write mix
- Traffic spikes
- Latency and consistency
- Store identity and access
- Storefront customization
- Checkout and stock
- Checkout retry identity
- Payment provider guarantees
- Durability, deployment, and exclusions
The interviewer has the answers. In a SysRound round, Alex gives these answers, as a real interviewer does.
Scope of a strong answer
Core requirements
- Create stores with separate domains and access roles.
- Manage products and publish storefront themes.
- Serve storefronts during sudden traffic spikes.
- Prevent stock oversell and repeated charges for the same checkout key within one year.
Usually out of scope
- Calculate taxes or shipping rates.
- Manage warehouses or fulfillment.
- Run merchant code on the platform.
- Build a payment provider or authentication service.
- Support checkout across several stores.
- Detect duplicate purchases that use different checkout keys.
What interviewers ask about
- Store boundaries
- The same application serves many stores. Hosts, access checks, caches, and background tasks must preserve the same store boundary.
- Storefront changes
- A storefront combines templates, assets, and catalog data. Publication must avoid incomplete releases while checkout still uses current prices.
- Traffic from one store
- A single store can consume much of the platform's capacity. A shared database or worker pool can spread that store's failure.
- Orders during failures
- Stock updates and external payments do not share a transaction. Retries and late payment results can create duplicate charges or invalid orders.
Common mistakes
- The design treats a store identifier as authorization.
- The design assumes separate domains provide data isolation.
- The cache omits the store identifier or stores private buyer responses.
- The design gives every store a database before it estimates the cost.
- The design relies on autoscaling without limits on shared resources.
- The checkout flow trusts stale prices or lacks a defined outcome for payments that succeed after stock release.
The bar by level
- Senior (L5/E5)
- Preserves store context across APIs, caches, and workers. Defines safe publication and per-store limits. Resolves checkout retries, reservation expiry, and late payments.
- Staff (L6+/E6+)
- Sets isolation guarantees and capacity budgets. Explains safe store migration and domain reassignment. Bounds payment guarantees by external contracts and defines recovery across failures.