Design Shopify

Problem Statement

Design a multi-tenant e-commerce SaaS platform like Shopify where merchants create online stores, manage products and inventory, process orders, and accept payments. The platform must isolate tenants, support custom storefronts, provide a webhook/API ecosystem for third-party apps, and handle flash sales where individual stores spike to 10,000x normal traffic.

Requirements

Functional

• Merchants create stores with custom domains, themes, and product catalogs
• Storefront rendering: server-side rendered product pages with custom themes (Liquid templates)
• Checkout: multi-step checkout with tax calculation, shipping options, and payment gateway integration
• Webhooks: notify third-party apps of events (order created, product updated, fulfillment shipped)

Non-Functional

• Multi-tenancy: Thousands of merchants share infrastructure, but one merchant's flash sale must not impact others
• Scale: 2M+ merchants, 500M+ buyers, peak 50K orders/minute across all stores
• Latency: Storefront pages render in <500ms, checkout in <3 seconds
• Reliability: 99.99% uptime for checkout -- downtime directly costs merchants revenue

Core Architecture

1. Storefront Rendering Engine -- Renders product pages using Liquid templates with merchant-specific themes. Each request identifies the store by custom domain (DNS CNAME) or subdomain. Templates are compiled and cached in Redis per store. Static assets (images, CSS, JS) are served via CDN. Server-side rendering ensures SEO friendliness.

2. Tenant-Aware Routing and Isolation -- A request router identifies the tenant from the domain, applies per-tenant rate limits, and routes to the appropriate application pod. Resource quotas prevent a single tenant from consuming excessive compute. During flash sales, the system auto-scales pods for the affected tenant while maintaining isolation.

3. Checkout and Payment Service -- Orchestrates the checkout flow: validate cart, calculate taxes (integration with tax APIs like Avalara), select shipping (carrier rate APIs), charge payment (Stripe, PayPal, Shop Pay). Uses the saga pattern for rollback. Generates an idempotency key per checkout attempt to prevent double charges.

4. Webhook Delivery System -- When events occur (order.created, product.updated), the system publishes to Kafka. A webhook dispatcher reads events, looks up subscribed app endpoints per merchant, and delivers via HTTP POST with HMAC signature. Failed deliveries retry with exponential backoff (5 attempts over 48 hours). Merchants can view delivery logs in the admin panel.

Database Choice

Sharded MySQL (Vitess) -- Shopify's actual architecture. Each shard holds data for a set of merchants (tenant-aware sharding by shop_id). This provides natural tenant isolation at the database level and enables per-shard scaling. Redis for storefront template cache, session storage, and rate limiting. Kafka for event bus (order events, webhooks, analytics). Elasticsearch for product search within each store.

Key API Endpoints

GET /api/v1/stores/\{store_id\}/products?collection=summer&sort=best_selling
  -> Returns: \{ products: [\{ id, title, price, images, variants, inventory_count \}] \}

POST /api/v1/stores/\{store_id\}/checkout
  -> Body: \{ cart_token: "CT-123", shipping_address: \{...\}, payment_token: "tok_..." \}
  -> Returns: \{ order_id: "ORD-456", confirmation_url: "...", total: 89.99 \}

POST /api/v1/webhooks
  -> Body: \{ topic: "orders/create", address: "https://app.example.com/webhooks", format: "json" \}

Scaling Insight

Pod-level tenant isolation is how Shopify survives flash sales. When Kylie Jenner drops a new product on her Shopify store, traffic spikes 10,000x in seconds. The routing layer detects the surge (request rate per shop_id), automatically spins up dedicated pods for that store, and routes its traffic there. Other merchants' traffic continues flowing to shared pods, completely unaffected. After the sale, dedicated pods are drained and returned to the shared pool. This is cheaper than permanently over-provisioning.

Key Tradeoffs

Practical Implementation for .NET Developers

In a .NET application, you would typically implement this pattern using the following approach:

ASP.NET Core setup: Create a service class that encapsulates the logic, register it with dependency injection, and inject it into your controllers or minimal API endpoints. The built-in DI container handles lifecycle management.

Entity Framework Core: For database interactions, EF Core provides the ORM layer. Use migrations for schema management and raw SQL for performance-critical queries. Consider Dapper for read-heavy paths where EF Core's overhead matters.

Azure integration: If deploying to Azure, leverage managed services — Azure Cache for Redis, Azure SQL, Azure Service Bus, Azure Cosmos DB. These eliminate operational overhead and provide built-in monitoring through Application Insights.

Testing: Use xUnit with Testcontainers for integration tests that spin up real databases in Docker. Mock external dependencies with NSubstitute. The WebApplicationFactory class lets you test your entire HTTP pipeline in-process.

Monitoring: Add Application Insights telemetry to track request latency, dependency calls, and custom metrics. Use structured logging with Serilog to make production debugging possible:

Log.Information("Processing order {OrderId} for {CustomerId}", orderId, customerId);

This gives you searchable, structured logs in Azure Monitor or Seq.

System-Specific Clarifying Questions

Before designing Shopify, ask questions specific to THIS system:

1. Who are the primary users? Understanding the user base shapes every technical decision — consumer apps have different requirements than enterprise B2B systems.
2. What is the read-to-write ratio? This determines whether you optimize for fast reads (caching, denormalization) or fast writes (write-ahead logs, async processing).
3. What is the geographic distribution? Users in one country vs. global users fundamentally changes your data replication and CDN strategy.
4. What is the acceptable latency? Some features need sub-100ms responses, others can tolerate seconds. This determines your caching and architecture strategy.
5. What is the consistency requirement? Some data (payments, inventory) needs strong consistency. Other data (social feeds, recommendations) can be eventually consistent.

Architecture Deep Dive

The architecture for Shopify should be designed around the specific access patterns of the system. Do not apply generic templates — every system has unique hotspots, bottlenecks, and scaling challenges.

Write Path: How does data enter the system? Is it bursty (event-driven, flash sales) or steady (sensor data, logs)? Bursty writes need queuing and backpressure. Steady writes can go directly to the database.

Read Path: How is data consumed? Is it fan-out (one write, many reads like social feeds) or point lookups (one read for specific data like user profiles)? Fan-out reads benefit from pre-computation and caching. Point lookups benefit from efficient indexing.

Hot Spots: Where are the bottlenecks? For Shopify, identify the component that will fail first under load and design mitigation strategies: caching, sharding, rate limiting, or async processing.

Sources

• Design Shopify -- Reference
• Source: System-Design-Overview