By ByteBot
Amazon Prime Video just confessed what pragmatic developers knew all along: their microservices architecture was burning money. Moving their video quality analysis system to a monolith slashed infrastructure costs by 90% while improving performance. This isn’t an isolated mea culpa—it’s the latest admission in a growing trend of companies abandoning the microservices dream that consulting firms and architecture astronauts sold them.
The confession validates years of developer frustration. For every Netflix successfully running microservices at scale, there are hundreds of startups drowning in operational complexity while serving traffic a single server could handle.
How We Got Here: Copying Netflix Without Netflix’s Problems
The microservices cargo cult started innocently enough. Netflix and Amazon published their success stories, and the industry cargo-culted their architecture without asking the critical question: do we have their problems? Netflix handles billions of requests with hundreds of engineers across independent teams. Most companies serve thousands of requests with fewer than 50 developers.
David Heinemeier Hansson nailed it: “You’re not Google. You don’t have Google’s problems.” Yet consulting firms pushed microservices as a maturity model, as if monoliths were somehow primitive. The truth? Microservices solve organizational scaling problems, not technical ones. If you don’t have multiple independent teams requiring deployment autonomy, you’re paying the microservices tax for nothing.
Resume-driven development accelerated the adoption. Engineers returning from BigTech pushed patterns that made sense at their previous employer’s scale but created chaos at startup scale. Architecture became fashion instead of engineering.
The Microservices Tax: Complexity That Never Ends
Every “independent” service multiplies operational overhead exponentially. Fifty microservices means fifty monitoring configurations, fifty deployment pipelines, fifty potential failure points, and debugging nightmares that span network boundaries. The promise of simplicity becomes an infrastructure management hellscape.
Segment learned this the hard way. After battling 140 microservices, they consolidated to roughly 20 larger services. Developer productivity returned. Outages decreased. The operational burden became manageable again.
Consider the performance penalty. An in-process function call takes roughly one nanosecond. An HTTP call between services? One to ten milliseconds. That’s 10,000 to 10,000,000 times slower. Multiply that across a request chain touching fifteen services, and you’ve architected latency into your system.
Related: Serverless Costs 10x More Than VPS – The Math Exposed
When Every Database Transaction Becomes a Distributed Systems Problem
Microservices evangelists gloss over the data consistency nightmare. ACID transactions work perfectly in monoliths—atomic, consistent, isolated, durable. Split your monolith into microservices, and suddenly every operation that used to be a single database transaction requires complex saga patterns or accepting eventual consistency.
Eventual consistency sounds reasonable until you explain to your e-commerce client that their inventory, payment, shipping, and notification services might be temporarily out of sync. That’s not a feature—that’s a data corruption window dressed up with architecture terminology.
Distributed transactions are effectively impossible. The two-phase commit pattern that looks elegant in architecture diagrams collapses under real-world network partitions and timeout cascades. Most applications need strong consistency. Microservices make that simple requirement extraordinarily complex.
Yes, Microservices Work—For the 5% Who Need Them
Microservices aren’t wrong. They’re massively over-applied. There are legitimate use cases, but they describe fewer than 5% of companies. You genuinely need microservices if you have extreme scale measured in billions of requests, multiple independent teams with clear domain boundaries, proven bottlenecks requiring component isolation, or regulatory boundaries demanding complete separation.
Netflix qualifies. Amazon qualifies. Your three-person startup absolutely does not. Even at significant scale, the case is questionable. Shopify handles billions in gross merchandise volume and Black Friday traffic spikes while running a modular Rails monolith. Scale alone doesn’t mandate microservices.
Martin Fowler, who helped popularize microservices, explicitly warns: “You shouldn’t start with microservices. Start with a monolith.” Even the pattern’s proponents acknowledge the “microservices premium”—the substantial upfront and ongoing cost you pay for the architecture. Most companies can’t justify that premium.
The Modular Monolith: What You Should Actually Build
The future isn’t microservices—it’s well-architected monoliths with enforced module boundaries. Use your language’s package system, namespaces, and dependency management tools to create logical separation within a single deployable unit. Deploy as one service. Split only when you have concrete evidence it’s necessary.
This isn’t theoretical. GitHub serves massive scale with a modular monolith. Basecamp has run for two decades on DHH’s “majestic monolith” philosophy, serving millions of users. Shopify processes enormous transaction volumes without fragmenting into dozens of services.
The pattern works because it preserves the benefits of modularity—clear boundaries, separated concerns, focused components—without the crushing operational overhead of distributed systems. You get ACID transactions, readable stack traces, simple deployments, and the ability to hire junior developers who can understand the full system.
Related: Monorepos Are Technical Debt: Why the Industry Got It Wrong
Can You Defend Your Microservices?
If you’re running microservices, ask yourself: can I defend why? Do we actually have Netflix-scale traffic? Do we have independent teams requiring deployment autonomy? Have we hit proven monolith limits? Or did we adopt microservices because it seemed like best practice, because our architect came from BigTech, or because “everyone else is doing it”?
Most honest answers reveal microservices were adopted for the wrong reasons. That’s not shameful—the entire industry was selling the pattern as inevitable evolution. But the correction is happening. Companies are quietly (and publicly) reverting to monoliths. The pragmatists are winning.
Key Takeaways
- Amazon Prime Video’s 90% cost reduction moving to a monolith isn’t an anomaly—it’s evidence that microservices create problems for most companies rather than solving them
- The microservices tax—operational complexity, infrastructure overhead, debugging nightmares, and data consistency challenges—is paid upfront and continuously
- Fewer than 5% of companies have the scale, organizational structure, or technical requirements that justify microservices architecture
- Modular monoliths with clear boundaries deliver the benefits of separation without the crushing costs of distribution—this should be your default architecture
- Start with a monolith. Enforce module boundaries. Scale vertically, then horizontally through replication. Split services only when concrete evidence demands it
Complexity is not sophistication. Good architecture beats distributed architecture. Your monolith is fine. Actually, it’s probably better.
