You’re under pressure to justify architectural decisions. Everyone’s telling you microservices are the only way to scale. But you’re looking at the operational complexity, the costs, the deployment headaches, and wondering if there’s a better path.
This guide is part of our comprehensive understanding of modern software architecture trends, where we explore the industry-wide architectural shift currently underway. Three major companies have publicly documented their moves to modular monoliths: Shopify, InfluxDB, and Amazon Prime Video. These aren’t small startups making questionable choices. These are engineering teams that tried microservices, measured the results, and decided to consolidate. And they’re sharing real numbers.
Shopify saved themselves from architectural chaos. InfluxDB cut their backend rewrite to three months with five people. Prime Video slashed infrastructure costs by 90%. Ninety percent.
And here’s the kicker – Martin Fowler, whose opinion on software architecture carries some weight, has been saying for years that you should start with a monolith. Almost all successful microservice stories started that way. Almost all cases where teams built microservices from scratch ended up in serious trouble.
Let’s look at how these companies actually did it.
How Does Shopify Manage 2.8 Million Lines of Code in a Modular Monolith?
Shopify runs on a 2.8 million line Ruby on Rails monolith. It serves millions of merchants. Hundreds of developers work in it every day. And it’s organised into 37 distinct components using Rails Engines.
This isn’t your typical “big ball of mud” monolith. They’ve got logical boundaries. They’ve got encapsulation. They’ve avoided all the operational complexity that comes with microservices whilst getting the modularity benefits they need.
The transformation took three years. Eighteen months in, they were already seeing improvements in how they triaged exceptions, upgraded frameworks, and maintained code quality.
As senior engineer Kirsten Westeinde put it: “I would actually recommend that new products and new companies start with a monolith.”
The Componentisation Approach
Rails Engines gave them the mechanism to create 37 logical modules in a single codebase. Each module has namespace isolation. Each has a potential extraction path if they ever need it. But they haven’t needed it.
The team recognised early on that this wasn’t just a technical challenge. They adopted Dr. B.J. Fogg’s Behaviour Model – lasting architectural change needs both capability and organisational buy-in.
Their first attempt focused on clean public interfaces. It wasn’t enough. They had to tackle the dependency graph. The original structure was a mess – nearly every component depended on over half of all the others. Circular dependencies everywhere.
So they built Wedge, an internal tool that tracked their isolation progress by analysing call graphs. When code violates component dependencies, it triggers runtime errors. Violations become visible immediately. The boundaries don’t erode gradually.
Enforcement Mechanisms
Packwerk is their static analysis tool. It examines constant references rather than runtime call graphs, which means it integrates into CI and rejects violations before they get merged.
They also brought in Sorbet, replacing runtime schema validation with static type checking. Contract enforcement with minimal performance overhead.
Then they reorganised the code. Instead of technical components – controllers, models, views – they restructured around business domains. Billing. Orders. Products. When you’re looking for code, you can actually find it.
The engineering team had a clear philosophy: “developers should feel like they are working on a much smaller app than they actually are.” They also recognised that “a single centralised team can’t make change happen by working against the momentum of hundreds of developers adding features.”
Beyond the usual “loose coupling and high cohesion” advice, Shopify prioritised something they call “change locality” – code that changes together should live together. And it starts at the class level. Well-designed individual classes enable well-designed components.
Why Did InfluxDB Completely Rewrite Their Backend from Microservices to a Rust Monolith?
InfluxDB took their time-series database from Go microservices to a unified Rust monolith. Why? To eliminate the operational complexity of distributed systems and improve performance.
A five-person team delivered the complete rewrite in three months using the Strangler Fig Pattern for migration. Zero downtime. Rust’s type system gave them compile-time correctness guarantees – entire classes of runtime errors just disappeared.
The platform team wanted to reduce complexity from both infrastructure and development perspectives. As more of their internal services moved to Rust, standardising on a single language made it easier for engineers to collaborate. No more constant context switching between languages and frameworks.
A monolith fit their team model perfectly: one team, one backend service, one language.
Migration Strategy and Architecture
The Strangler Fig Pattern let them replace things incrementally whilst keeping the system available. Integration tests validated that the old and new systems behaved the same way. They migrated three API versions at once – v0 REST, gRPC, and v1 REST.
They used hexagonal architecture patterns to isolate business logic from infrastructure concerns. Domain-driven design guided where the boundaries should go. The upfront domain modelling paid off – it enabled rapid delivery despite completely changing the technology stack.
Technology Choice: Why Rust?
Rust’s type system is what sold them. Compile-time correctness guarantees. Explicit handling of nullable values and error conditions. For a database handling high-volume time-series workloads, these guarantees translated directly into reliability improvements.
Performance improved from eliminating network hops between services. Deployment got simpler. The type-safe codebase prevented entire categories of production issues.
How Did Amazon Prime Video Achieve 90% Cost Reduction Through Architectural Consolidation?
Amazon Prime Video consolidated their distributed monitoring system. They went from AWS Step Functions and Lambda to a unified service running on EC2 and ECS. Infrastructure costs dropped 90%, demonstrating the real cost implications of microservices at scale.
They needed to monitor every customer stream. That’s thousands of concurrent executions. Serverless state machine orchestration became prohibitively expensive at that scale.
AWS Step Functions charges per state transition. With thousands of concurrent streams, the costs multiplied dramatically. Then there were the S3 costs. High tier-1 calls for temporary storage of captured video frames.
The team realised something important: “We realised that distributed approach wasn’t bringing a lot of benefits in our specific use case, so we packed all the components into a single process.” That eliminated S3 intermediate storage entirely.
Scale Requirements and Cost Drivers
Monitoring “every stream viewed by customers” meant handling “thousands of concurrent streams.” At that scale, serverless pricing went from being an advantage to a liability.
AWS’s serverless services are optimised for sporadic workloads with variable demand. But for high-volume sustained processing like Prime Video’s monitoring workload, reserved capacity through EC2 and ECS provides better economics.
Architectural Changes and Results
The consolidated solution now runs on EC2 and ECS. They’ve got “a lightweight orchestration layer to distribute customer requests” instead of complex Step Functions state machines.
Moving all components into a single process enabled in-memory data transfer. That broke through the 5% scaling ceiling their distributed architecture hit.
Think about the performance difference here. In-memory monolith calls take nanoseconds. Microservice network calls take milliseconds. That’s a 1,000,000x difference. When a single request spans five microservices, you’re burning 50-100ms on network overhead alone.
AWS Contradiction and Lessons
Here’s where it gets interesting. An internal Amazon team chose against AWS’s own prescribed serverless patterns. The economics didn’t align. Context-specific decision-making mattered more than pattern-following.
Serverless remains optimal for sporadic workloads. But for high-volume sustained processing, consolidated architectures win. Right-sizing your architectural decisions to actual requirements delivers better outcomes than blindly following recommended patterns.
What Common Patterns Emerge Across These Successful Modular Monolith Migrations?
All three companies maintained logical boundaries and modularity. Rails Engines at Shopify. Hexagonal architecture at InfluxDB. Service boundaries within processes at Prime Video. None of them reverted to unstructured designs.
They all used incremental migration strategies. This managed risk and maintained business continuity. They all built strong tooling and enforcement mechanisms to prevent architectural erosion. And they all achieved quantified business outcomes – cost reduction, performance gains, developer productivity improvements – that justified the architectural decisions to stakeholders.
What’s emerging isn’t a complete rejection of microservices. It’s a more nuanced approach. Instead of pushing for the smallest possible services, organisations are finding value in “right-sizing” services around complete business capabilities.
Domain-Driven Design Influence
Domain-driven design provided the conceptual frameworks for defining module boundaries. Bounded contexts and ubiquitous language guided the work.
InfluxDB explicitly used DDD for their hexagonal architecture design. Shopify applied DDD through subdomain-based componentisation.
When you apply DDD principles, you align software modularisation with business objectives. That’s how you keep the boundaries stable as the system evolves.
What Does Martin Fowler’s “Monolith First” Guidance Actually Say?
Martin Fowler’s “Monolith First” article recommends starting with well-structured monoliths before considering microservices.
Here’s his key observation: Almost all successful microservice stories started with monoliths that got too big and were broken up. Almost all cases where systems were built as microservices from scratch ended up in serious trouble.
“You shouldn’t start a new project with microservices, even if you’re sure your application will be big enough to make it worthwhile,” Fowler advises. Microservices incur what he calls a “MicroservicePremium” – the cost of managing a suite of services.
The first reason for monolith-first is classic YAGNI – You Aren’t Gonna Need It. When you’re beginning a new application, how certain are you it will even be useful to users?
It may be hard to scale poorly designed but successful software. But that’s still better than the inverse. Often the best way to find out if software ideas are useful is building simplistic versions and seeing how well they work out.
So build new applications as monoliths initially. Extract services when clear scaling or isolation needs emerge, not preemptively.
What Quantified Results Did These Companies Achieve Through Modular Monolith Adoption?
The three case studies demonstrate different but equally compelling outcomes. Cost optimisation. Delivery velocity. Sustained productivity. Each represents a distinct business value proposition for architectural consolidation.
Prime Video achieved that 90% cost reduction by switching from per-execution to reserved capacity pricing models.
InfluxDB delivered a complete backend rewrite in three months with a five-person team.
Shopify maintains hundreds of developers working productively through componentisation.
One documented consolidation delivered these numbers: response time 1.2s to 89ms (93% faster), AWS costs $18,000/month to $2,400/month (87% reduction), deployment time 45 minutes to 6 minutes (86% faster), bug count reduced by 70%, and traffic capacity increased by 10x.
All three implementations achieved operational simplification. That reduced cognitive load, deployment complexity, and the effort required to understand the system. As Shopify engineers explained: “We’ve built tooling that gives us many microservices benefits—like isolation and developer independence—without the operational cost of maintaining hundreds of different services.”
Performance improved from eliminating network hops. Deployment got simpler – single-unit deployments replaced distributed system orchestration. Infrastructure surface areas shrank, creating fewer failure modes and clearer debugging paths.
FAQ
What is a modular monolith and how does it differ from traditional monoliths?
A modular monolith is a single deployable application that’s organised into well-defined, loosely-coupled modules with explicit dependencies and enforced boundaries.
Unlike traditional monoliths – the “big ball of mud” – modular monoliths maintain logical separation through componentisation, dependency management, and encapsulation. You get the modularity benefits of microservices without the distribution complexity. Shopify’s 37 Rails Engines and InfluxDB’s hexagonal architecture show how this works in practice.
When should you choose a modular monolith over microservices?
Choose modular monoliths when the operational complexity of distributed systems outweighs the benefits. Single teams. Shared data domains. Performance-sensitive workloads. Cost-conscious environments. Unproven scale requirements.
Martin Fowler’s “Monolith First” recommends starting with well-structured monoliths even for systems you expect to eventually distribute. This allows natural service boundaries to emerge through operational experience rather than upfront speculation.
How long does it take to migrate from microservices to a modular monolith?
InfluxDB’s complete rewrite took three months with a five-person team using the Strangler Fig Pattern approach.
Shopify’s componentisation of an existing monolith took 18+ months across hundreds of developers.
Your timeline depends on migration strategy – incremental versus rewrite – system complexity, team size, and business continuity requirements.
What tools enforce boundaries in modular monoliths?
Shopify uses Packwerk for Ruby dependency enforcement and Sorbet for type checking.
InfluxDB relies on Rust’s compile-time type system – Option
General approaches include static analysis tools, dependency graphing, integration testing in CI/CD pipelines, and architectural fitness functions that detect boundary violations automatically.
Can modular monoliths scale to the same level as microservices?
Yes. Shopify operates 2.8M lines serving millions of merchants. Amazon Prime Video monitors thousands of concurrent streams. InfluxDB handles high-volume time-series workloads.
Scaling approaches differ though. Vertical scaling. Deployment replication. Caching strategies. Database optimisation. And selective extraction of genuinely independent bounded contexts when proven necessary.
What are the main challenges when consolidating microservices?
Managing dual architecture during transition. Maintaining feature velocity whilst refactoring. Breaking tight coupling that microservices masked. Retraining teams on monolithic deployment models. Handling data consolidation across previously distributed databases. Justifying the investment in architectural improvement to stakeholders focused on feature delivery.
How do you maintain team autonomy in a modular monolith?
Component ownership replicates microservices team structure within a single codebase. Shopify assigns teams to specific Rails Engines with clear boundaries.
Packwerk and similar tools enforce ownership through dependency rules. CI/CD pipelines enable independent deployment cadences through feature flags. Clear interfaces between modules allow parallel work without coordination overhead.
What role does domain-driven design play in modular monolith success?
Domain-driven design provides the conceptual framework for defining module boundaries through bounded contexts and ubiquitous language.
InfluxDB explicitly used DDD for their hexagonal architecture implementation. Shopify applied DDD through subdomain-based componentisation.
DDD ensures modules align with business domains rather than technical layers. That creates stable boundaries that reflect the real-world problem space.
Why did Amazon Prime Video’s consolidation contradict AWS best practices?
Prime Video’s monitoring workload required thousands of concurrent executions. That made serverless per-execution pricing prohibitively expensive.
AWS prescriptive guidance optimises for general cases. But high-volume sustained workloads economically favour reserved capacity – EC2 and ECS – over serverless like Step Functions and Lambda. This demonstrates the importance of context-specific decision-making over pattern-following.
How do you know if your microservices should be consolidated?
Look for these warning signs: excessive network latency impacting performance, distributed transaction complexity, high operational overhead relative to team size, difficulty reasoning about system behaviour, cost structures favouring reserved capacity, tight coupling between services requiring coordinated deployments, and limited independent scaling needs.
Quantify the pain points – cost, latency, deployment frequency – before you decide.
What prevents modular monoliths from becoming “big ball of mud”?
Enforcement mechanisms. Static analysis tools like Packwerk. Type systems like Rust and Sorbet. Automated dependency graphing. CI/CD architectural fitness functions. Change locality monitoring.
Organisational practices matter too. Component ownership. Clear interface definitions. Regular refactoring. Architectural decision records. Technology choices that support modularity – Rails Engines, hexagonal architecture.
Can you extract microservices from a modular monolith later if needed?
Yes. Well-structured modular monoliths create extraction paths through clear boundaries and explicit dependencies.
Shopify’s Rails Engines could become standalone services if required. InfluxDB’s hexagonal architecture isolates business logic from infrastructure.
The key is maintaining logical separation even within a single deployment. That allows physical distribution when operationally justified through proven scaling requirements rather than speculation.
These case studies demonstrate that consolidation represents architectural maturity, not failure. The companies achieved quantified business outcomes whilst maintaining the modularity and team autonomy that microservices promised but failed to deliver economically. For a complete overview of the architectural consolidation movement and how to navigate these decisions, see our comprehensive guide to modern software architecture.
