How Shopify Scales 30 TB per Minute with a Monolithic Architecture

Monolithic Architecture at Scale

Shopify processes more than 30 TB of data per minute and over 32 million requests per minute during peak events such as Black Friday, yet its core system remains a single, well‑structured monolith rather than a sprawling micro‑service mesh.

Modular Monolith Built with Ruby on Rails

The platform is a modular monolith written primarily in Ruby on Rails. The codebase is a single repository, but logical boundaries divide it into independent modules (checkout, payment, orders, admin, inventory, analytics). Each module owns its own data, public API, and maintenance team, allowing isolated development and deployment.

Hexagonal (Ports & Adapters) Design

Shopify applies the hexagonal architecture (also known as the ports‑and‑adapters pattern) to keep core business logic independent of external concerns such as APIs, databases, or message queues. The core is a hexagon; adapters sit on the edges to translate external interactions.

────────────────────────┐
│          Web Layer           │
│ (GraphQL, REST, Mobile APIs) │
└──────────────────┬───────────────────┘
                     │
                     ▼
    ┌────────────────────────────┐
    │   Application Service      │
    │ (CreateOrderUseCase Port) │
    └────────────┬───────────────┘
                 │
          (via Interface)
                 │
    ┌────────────────────────────┐
    │        Adapters            │
    │ (MySQL, Kafka, Redis etc.) │
    └────────────────────────────┘

Pods – Isolated Clusters Within the Monolith

To achieve horizontal isolation, Shopify runs multiple Pods . Each Pod is a self‑contained mini‑Shopify with its own database shard, cache, task queue, and worker processes. A routing service called Sorting Hat directs incoming traffic to the appropriate Pod, ensuring failures are contained.

Data Pipeline Evolution

Shopify migrated from a batch‑oriented system ( Longboat ) to a real‑time change‑data‑capture pipeline using Debezium + Kafka . Every database change—new orders, refunds, updates—now streams instantly into Kafka, enabling petabyte‑scale real‑time dashboards, fraud detection, and analytics.

Handling Traffic Peaks Gracefully

During extreme spikes (e.g., a celebrity product launch), Shopify relies on edge CDN caching, Redis/Memcached for session and pre‑computed data, background queues for heavy tasks, and an graceful degradation strategy that pauses non‑essential features while keeping checkout fully operational.

Edge cache (CDN) : serves static assets.

Redis/Memcached : fast reads for sessions and pre‑computed data.

Background queues : offload email, webhooks, analytics.

Graceful degradation : non‑core functions auto‑pause under load.

MySQL at Massive Scale

Shopify continues to use MySQL as its primary datastore, but it is sharded across hundreds of partitions distributed among Pods. The system handles over 10 million queries per second , provides automatic cross‑replica load balancing, snapshot‑based backups with a 30‑minute recovery window, and online schema changes with zero downtime.

Hundreds of shards across Pods.

>10 million queries per second.

Automatic cross‑replica load balancing.

Snapshot backups, 30‑minute recovery.

Online schema changes, zero downtime.

Key Lessons for Large‑Scale Systems

Start with a monolith and evolve toward modularity; avoid premature micro‑service fragmentation.

Apply hexagonal architecture to keep business logic decoupled from I/O.

Isolate failures using Pods, shards, or domain boundaries.

Prefer streaming pipelines over batch processing for real‑time insight.

Plan graceful degradation to protect core functionality.

Make the architecture appear simple; simplicity is a sign of engineering excellence.

Final Thoughts

Shopify’s experience shows that a well‑designed, disciplined monolithic architecture—augmented with modular boundaries, hexagonal principles, and robust isolation—can scale to internet‑level traffic while remaining maintainable and performant, challenging the notion that only micro‑service chaos can handle such load.