Scaling without splitting: a decade of Shopify, read from the code it published
How Shopify kept one Rails application as its unit of deployment between 2014 and 2026, and what it changed underneath the application instead: static boundary checks, in-driver circuit breakers, a live shard mover and two JIT compilers.
A decade of one company's architecture, reconstructed from the ring of repositories around a closed monolith: a boundary checker whose stricter half was removed, a resilience library that sizes bulkheads from an occupancy probability, a MySQL shard mover with a committed TLA+ model and four published corruption defects, and two compilers written for the language the application runs on. A reader leaves with a decision tree for which boundary they can actually afford, a transferable taxonomy of silent-corruption classes in live data movement, and the conditions under which each of these choices stops being right.
The company that chose static analysis over service boundaries then deleted half of its own boundary model: packwerk shipped with dependency and visibility checks in 2020, and the visibility checker was pulled out of the core gem in November 2022 and released as a breaking change in v3.0.0 on 1 March 2023, leaving only the rule that needs no knowledge of intent.
What you get out of it
- Only the boundary rule that can be decided without design intent survived in the core checker; the one encoding opinion was moved to an optional gem.
- Overload protection is sized as a chosen error budget: a 10% occupancy estimate yields five tickets and an explicitly accepted 0.001% false-positive rate.
- A verifier built on the mover's own model cannot catch an error in that model, which the project states in its own documentation and then demonstrates with a binlog-position defect no online verifier can detect.
- Three of the four published data-movement defects are silent by construction: type equality, identifier ordering and result-column order each fail without raising.
- Performance work left the application entirely: production object-shape and GC measurements are carried upstream into Rails and CRuby rather than fixed in the monolith.
Scope
Why this, now. Shopify upstreamed a second JIT compiler in April 2025 and was still fixing the Ruby VM's heap sizing from monolith production data in August 2026, so the strategy of pushing scale problems downward rather than outward can now be read across a full ten years with both its early and its late decisions visible.
What it does not cover. No engineering blogs, papers, talks hosted off-repository, issue threads, traffic figures or cost analysis: this session's network policy reached code hosts, one vendor page and a package index only, so the monolith's internals, its scale and its availability record are all outside the corpus, and Shopify publishes no incident reviews that could be reached.
Other field guides
Keeping the main branch green: thirteen years of merge queues, read from the repositories that ran them
The merge-queue pattern traced through its primary record: Rust's three generations of bors, Zuul's speculative gating, Kubernetes' Tide, GitLab's tr…
20 sources · 11 organisations · 2 postmortemsTwo hundred control planes per cluster: ten years of SAP's Gardener
A fleet platform has to give hundreds of teams their own cluster, on whichever infrastructure each product sells on, cheaply enough that asking for o…
34 sources · 4 organisations · 3 postmortemsThe parts that outlived the product: ten years of Docker, read from its own repositories
A decade of one company's architecture told through the sequence every platform team eventually faces: bundle to win the workflow, extract components…
38 sources · 9 organisations · 5 postmortems