Skip to content

How a Shopify-like commerce platform might evolve

Millions of independent stores on one platform, and any one of them can receive a flash sale bigger than most companies' Black Friday. How multi-tenancy, pods of shards, traffic spikes and checkout reliability shape a commerce platform.

The user problem and the hard parts

A merchant wants a store that is always up, fast, and never loses an order, without hiring engineers. Shoppers want a quick checkout. The platform wants to serve millions of merchants on shared infrastructure at a low cost per store.

The hard engineering problems:

  • Multi-tenancy: every store's data must be isolated (no store ever sees another's orders), yet sharing infrastructure is what makes the price affordable.
  • Flash sales: a celebrity product drop can send hundreds of thousands of shoppers to one store in the same minute. That store is a tiny tenant 364 days a year.
  • Noisy neighbours: one tenant's spike must not slow down the other tenants on the same database.
  • Checkout reliability: inventory must not oversell, payment must not double-charge, and checkout must keep working when the storefront is under heavy load.
  • Extensibility: themes, apps and custom scripts from third parties run on the platform and must not break it.
Tenant
One customer of a SaaS platform; here, one store. All its data shares a shop_id.
Shard
One partition of the data held by a separate database. See .
Pod
A self-contained slice of the platform: a database shard plus the caches, queues and workers that serve the tenants assigned to it. Shopify has publicly described this pod model.
Noisy neighbour
A tenant whose load degrades service for others sharing the same resources.

How the architecture might evolve

A Shopify-like commerce platform

A plausible architecture for a multi-tenant commerce platform at each scale. Shopify has publicly described its Rails modular monolith and its pod-based database sharding; the rest is illustrative.

  1. 1
    Stage 1 · Store builder
    1k stores · 10k orders/day
    Web monolith (e.g. Rails)One MySQL/PostgreSQL database, `shop_id` on every tablePayment providerCDN for themes and product imagesBackground jobs

    Shared schema with a tenant column is the cheapest multi-tenancy model. Every query is scoped by shop_id, enforced in the data-access layer, not left to each developer.

  2. 2
    Stage 2 · Growing platform
    100k stores · 1M orders/day
    Read replicasPage and fragment caching for storefrontsJob queues with per-shop fairnessApp platform with API rate limits per app/shop

    Storefront reads are cacheable and dominate traffic. Third-party apps hammer the API, so rate limits per app and per shop protect the database.

  3. 3
    Stage 3 · Sharded pods
    1M+ stores · flash sales of 100k+ shoppers/min
    Database sharded by shop into pods (each pod = DB + Redis + workers)Routing layer mapping shop → podTenant move tooling between podsStorefront rendering separated from admin and checkoutModular monolith with enforced component boundaries

    No single database can hold every tenant, and tenants rarely interact, so shop is the natural shard key. Pods contain failures: one overloaded pod affects only its tenants.

  4. 4
    Stage 4 · Global commerce
    Global · millions of merchants
    Multi-region pods with failoverEdge-rendered storefrontsCheckout as a hardened, independently scaled pathLoad shedding and queueing for extreme salesLarge-scale load-testing in production-like environments

    Storefront latency matters globally, so rendering moves to the edge. Checkout is where money is made, so it gets isolation, priority and the most conservative change process.

Pods, routing and a flash sale

A plausible architecture for Stage 3 might look like this. Tenants are grouped into pods; a router sends each request to its tenant's pod.

Click a component

Click any component to see what it does.

Engineering trade-offs

Shared schema, tenant column

  • Cheapest per tenant
  • One migration for all tenants
  • A missing WHERE shop_id leaks data
  • Noisy neighbours share everything
Choose when: Many small tenants; enforce scoping in a shared data layer.

Database per tenant

  • Strong isolation
  • Easy per-tenant backup and deletion
  • Millions of databases to migrate and monitor
  • Poor resource utilisation
Choose when: Few, large, high-value tenants with strict isolation needs.

Pods: groups of tenants per shard

  • Bounded blast radius
  • Scale by adding pods
  • Big tenants can be moved to quieter pods
  • Routing layer and tenant-move tooling
  • Cross-pod queries need a separate data path
Choose when: Large multi-tenant platforms where tenants are independent.

Practical exercise

The 1,000-pair sneaker drop

A small store on your platform announces a limited sneaker release: 1,000 pairs at 18:00. You expect 300,000 shoppers to press "Buy" within one minute. The store shares a pod with 20,000 other shops. Design for no overselling, a fair experience, and no impact on the other shops.