Shopify

Multi-tenant commerce platform

Design a platform where millions of merchants each run their own online store on shared infrastructure, and one store's flash sale never takes the others down.

Overview

Designing a single online store is one problem. Designing the platform that runs millions of stores is a different one: every merchant has their own domain, theme, products, orders and apps, but they all share the same fleet. The question the interviewer really asks is how you share that fleet without one merchant hurting another.

The design rests on two facts. First, almost all data belongs to exactly one store, so the store (the shop) is a natural key for splitting data. Second, load is extremely uneven: a merchant launching a limited product can send more checkout traffic in a minute than thousands of ordinary stores do in a day. Averages are useless; the design must survive the busiest shop.

Shopify has written publicly about how it solves this: pods (isolated sets of datastores, each holding a subset of shops), a routing table at the edge, a separate storefront renderer for read traffic, a checkout queue for flash sales, and tools to move shops between pods without downtime. This topic uses those posts and talks, cited at the end, and marks everything else as a design choice.

Questions to ask first

How many stores, how big? — 2 million active stores; most small, a few very large
Traffic? — 2 billion storefront page views and 10 million orders a day; sale days 10 times higher
Custom domains? — Yes; every store also has a platform subdomain
Can merchants customize the storefront? — Yes, with themes in a safe template language
Payments? — Cards through the platform, tokenized; other methods through external providers
Third-party apps? — Yes; they call a rate-limited API and receive webhooks
Cross-store features? — Only in separate systems (analytics, a shared buyer wallet), not in the store data path

What you will be able to do

Compare shared-everything, shared-nothing and pod-based tenancy, and defend pods.
Route a request from a custom domain to the pod holding its store.
Keep one store's flash sale from starving its neighbors, with a fair checkout queue.
Keep card data out of most of the codebase by tokenizing it in an isolated service.
Move a store to another shard online, with seconds of write downtime.

Key concepts

Multi-tenancy
Pods
Tenant routing table
shop_id sharding key
Noisy neighbors
Checkout queue
Card tokenization
Online shop moves
Leaky-bucket API limits

Functional requirements

A merchant creates a store with a platform subdomain and can attach a custom domain
Merchants manage products, variants, inventory per location, and a theme
Buyers browse the storefront, fill a cart and check out with a card or another method
Orders appear in the merchant admin; fulfillment updates stock and notifies the buyer
Third-party apps read and write store data through an API and receive webhooks

Non-functional requirements

A problem in one store, or one group of stores, never affects stores elsewhere
Storefront pages answer in under 200 ms of server time for most requests (a target we chose)
Checkout never oversells, never charges twice, and degrades into a queue rather than errors under load
Card data never reaches the main application or merchant themes
Stores can be rebalanced across shards with seconds of write downtime, not hours

Interview questions

How do you isolate tenants without giving each one its own database?
How does a request for a custom domain reach the right data?
One merchant's product drop sends 100 times its normal traffic. What happens?
How do you move a store between shards without downtime?
How do you keep card numbers out of the main application?
Why use a separate storefront renderer?
How do you stop third-party apps from overloading a store?
What would you build first if this were a startup?