---
title: "Deconstructing the Monolith - Shopify"
description: "Shopify describes why its decade-old Ruby on Rails monolith became difficult to change as the codebase and development organization grew. High coupling and absent boundaries made innocuous changes trigger unrelated test failures, slowed CI, and forced developers to absorb excessive domain context, while microservices would add deployment, infrastructure, network, and coordination costs. The chosen path was a modular monolith: retain one codebase and deployment unit while separating domains through strictly enforced component boundaries. Shopify’s Componentization effort was informed by a developer survey and uses Wedge to score components and report violations, including cross-component associations and calls that bypass explicitly public interfaces. Boundary enforcement at runtime remains a future goal, but dependency isolation has already enabled replacing a legacy tax engine with a new tax calculation system."
---

# Deconstructing the Monolith - Shopify

[Shopify](https://yomu.fyi/company/shopify) · 2023-10-18 · Feb 21, 2019

**Type:** Problem & solution

## Summary

Shopify describes why its decade-old Ruby on Rails monolith became difficult to change as the codebase and development organization grew. High coupling and absent boundaries made innocuous changes trigger unrelated test failures, slowed CI, and forced developers to absorb excessive domain context, while microservices would add deployment, infrastructure, network, and coordination costs. The chosen path was a modular monolith: retain one codebase and deployment unit while separating domains through strictly enforced component boundaries. Shopify’s Componentization effort was informed by a developer survey and uses Wedge to score components and report violations, including cross-component associations and calls that bypass explicitly public interfaces. Boundary enforcement at runtime remains a future goal, but dependency isolation has already enabled replacing a legacy tax engine with a new tax calculation system.

## Context

Shopify’s large, long-lived Rails monolith accumulated high coupling and lacked boundaries between business domains. This made changes fragile, tests difficult and slow, and onboarding demanding; microservices were considered but would introduce additional infrastructure, network, and coordination costs.

## Approach / What changed

Shopify chose a modular monolith through its Componentization effort: keep one codebase and deployment unit while defining and tracking boundaries between domains. A developer survey informed the work, and Wedge scores components and lists violations. Programmatic runtime enforcement and further dependency untangling were identified as longer-term goals.

## Takeaways

- The monolith’s high coupling caused seemingly minor changes to trigger unrelated test failures and made CI tests difficult and slow.
- Shopify’s modular monolith preserves a single application while requiring domains to interact through explicitly public interfaces.
- Dependency isolation made it possible to replace a legacy tax engine with a completely new tax calculation system.

**Tags:** [Architecture](https://yomu.fyi/topic/architecture), [Monoliths](https://yomu.fyi/topic/monolith), [Refactoring](https://yomu.fyi/topic/refactoring), [Ruby on Rails](https://yomu.fyi/topic/ruby-on-rails)

- Source: [Shopify](https://shopify.engineering/deconstructing-monolith-designing-software-maximizes-developer-productivity)
- Source URL: https://shopify.engineering/deconstructing-monolith-designing-software-maximizes-developer-productivity
- Ingested by Yomu: 2026-08-31T04:00:58.850Z

[Read original post](https://shopify.engineering/deconstructing-monolith-designing-software-maximizes-developer-productivity)