By Amazon Prime Video cut infrastructure costs by 90% after ditching their microservices architecture for a monolith. The irony is striking—the company that helped popularized distributed systems is now proving that sometimes the simplest solution wins. In 2025, the pendulum is swinging back from a decade of microservices vs monolith debates to pragmatic simplicity, and the industry consensus is clear: if your team has fewer than 50 developers, you probably don’t need microservices.
This isn’t about monoliths being “better” than microservices. It’s about finally admitting that microservices were oversold, often adopted for the wrong reasons, and that architectural decisions should be driven by actual constraints—not by what worked for Netflix.
Team Size Is the Real Decision Factor
The 2025 consensus cuts through years of “it depends” hand-waving with concrete thresholds: microservices benefits only appear with teams larger than 10 developers. Below this, monolithic architecture consistently outperforms. The math is brutal—microservices require 3 to 5 developers per service to maintain properly. A 15-person team managing 12 services isn’t being agile; they’re drowning.
Martin Fowler calls this the “Microservice Premium”—a productivity cost that only pays off in sufficiently complex systems. Small teams end up spending more time debugging network issues and maintaining deployment pipelines than actually building features. The operational overhead (distributed tracing, centralized logging, orchestration) becomes the product instead of supporting it.
The financial threshold is just as clear: microservices make sense at $10 million+ annual revenue or 50+ developers. Below that, the coordination costs don’t justify the distributed system complexity. For the 10-50 developer range, modular monoliths offer the best of both worlds—enforced module boundaries without the operational burden of distribution.
When Amazon Moves Back, Listen
Amazon Prime Video’s Video Quality Analysis team migrated from a distributed microservices architecture using AWS Step Functions to a single-process monolith. The result: 90% infrastructure cost reduction plus improved scaling capabilities. They eliminated expensive S3 calls for intermediate frame storage by moving data transfer in-memory.
This wasn’t a small startup cutting corners to survive—this is Amazon, the company that pioneered modern microservices architecture, proving that monoliths work at scale when the use case fits. The key lesson: architectural choice is case-by-case, not one-size-fits-all. This was one component of Prime Video; the rest of Amazon still runs on microservices where it makes sense.
The move validates what many developers have felt but hesitated to say: sometimes the technology industry over-engineers solutions to problems we don’t actually have. Amazon’s reversal gives permission to choose simplicity without being dismissed as “not understanding modern architecture.”
Modular Monoliths: The New Consensus
The modular monolith architectural pattern has emerged as the pragmatic middle ground. It structures applications into independent modules with enforced boundaries—all within a single deployable artifact. You get modularity without distributed system complexity.
Shopify maintains a 2.8-million-line Ruby monolith serving millions of merchants worldwide. Their modular approach uses “podded architecture”—splitting databases, not services—and tools like Packwerk to enforce module boundaries. They extract microservices only for specific needs like checkout and fraud detection, keeping their core as a modular monolith. The result: 19 million queries per second on MySQL with 1,000+ developers working in the same codebase.
GitHub tells a similar story: 50 million developers, 100 million repositories, and 1 billion API calls per day—all on a 2-million-line Rails monolith. They deploy 20 times per day and maintain their own version of Ruby. Their gradual transition to a hybrid architecture keeps the monolith as the core while extracting select microservices only when data proves the need.
These aren’t legacy systems limping along—they’re proof that monoliths scale massively when built with discipline. The difference between a “Big Ball of Mud” and a scalable monolith is enforced boundaries, not physical service separation.
What Microservices Actually Cost
Fowler’s warning about the Microservice Premium proves accurate in practice. Distribution complexity means remote calls are slow and unreliable, requiring asynchronous programming patterns that add cognitive overhead. Eventual consistency across multiple databases forces developers to manage stale data and conflict resolution—problems that don’t exist in monoliths with ACID transactions.
The operational prerequisites are significant: continuous delivery capability (not optional), DevOps culture with skilled operations teams, well-understood domain boundaries, and comprehensive monitoring. Teams without these capabilities struggle. As Fowler puts it: “If you can manage your system’s complexity with a monolithic architecture then you shouldn’t be using microservices.”
The hidden cost is velocity. A five-person team can easily spend more time maintaining pipelines and debugging distributed systems than shipping features. The promise of independent deployment becomes meaningless when every change requires coordinating across service boundaries that shouldn’t exist yet.
So What Should You Choose?
The decision framework for 2025 is straightforward: start with a monolith unless you have a compelling reason not to. Almost every project benefits from beginning simple and evolving when real constraints demand it.
For teams under 10 developers, the monolith wins decisively. Focus on shipping features, not managing infrastructure. The 10-50 developer range is where modular monoliths shine—enforced boundaries prevent architectural erosion while avoiding distributed system complexity. At 50+ developers or $10 million+ revenue, microservices benefits finally justify the operational costs.
Extract services only when data proves the need: measured performance bottlenecks, dramatically different scaling requirements (one service handling 100x more traffic), or genuine technology diversity needs (Python ML models with a Java API). Don’t extract because “we might need to scale this differently someday.”
The religious wars are over. Pragmatism won. Build the simplest architecture that solves your actual problems. You can always evolve later when real constraints demand it—and companies like Shopify and GitHub prove that “later” might never need to come.
Key Takeaways
- Team size matters most: under 10 developers stick with monoliths, 10-50 use modular monoliths, 50+ consider microservices
- Amazon Prime Video’s 90% cost savings prove monoliths aren’t legacy—they’re often the smarter choice
- Shopify (2.8M lines) and GitHub (50M users) demonstrate monoliths scale massively with proper boundaries
- Microservices require continuous delivery, DevOps maturity, and $10M+ revenue to justify operational complexity
- Start simple, evolve when data proves you need complexity—not because everyone else is doing it
