In 2023, Amazon Prime Video made a decision that sounded like architectural heresy. They dismantled their serverless, distributed microservices infrastructure and replaced it with a monolith. The result: 90% infrastructure cost reduction and dramatically simplified operations. Engineering Twitter had opinions. But the Prime Video team wasn't confessing failure — they were reporting success. And they weren't alone. Across the industry, a quiet reconsideration of microservices dogma is underway. The architecture that was supposed to enable scale is increasingly recognized as a tax on engineering velocity that many organizations can't afford.

The Premise That Became Orthodoxy

Microservices emerged from legitimate problems. Monolithic codebases grow unwieldy. Teams step on each other's changes. Deployments become high-risk events. The logic was sound: break the monolith into independently deployable services, let teams own their domains, and scale components separately. In theory, each service is simple. In practice, the system becomes complex.

The shift happened gradually then suddenly. Between 2015 and 2020, microservices became the default architecture for any serious engineering organization. Job postings required "microservices experience." Conference talks praised distributed architectures. Vendor marketing sold Kubernetes and service mesh as infrastructure essentials. If you weren't building microservices, you weren't building for scale.

The assumption became invisible: of course you need microservices. The question was only how many and how to manage them. But that assumption deserves scrutiny. Because the data emerging from organizations that have run both architectures suggests the costs of microservices are systematically underestimated while the benefits are systematically overstated.

The Coordination Tax

The hidden cost of microservices isn't infrastructure — it's coordination. Every service boundary creates an interface that must be defined, versioned, documented, and maintained. Changes that would be internal refactorings in a monolith become cross-team coordination efforts. The cognitive load compounds non-linearly.

Consider the developer experience. In a monolith, an engineer can understand the codebase, make changes, run tests, and deploy with confidence. In a microservices architecture, the same engineer needs to understand service boundaries, API contracts, deployment dependencies, and failure modes across dozens of potential interactions. The context required to make safe changes expands from "this codebase" to "this distributed system."

This isn't just inconvenient — it's expensive. Engineering time is the primary constraint in software development. Every hour spent coordinating across services is an hour not spent building features. Every mental cycle spent reasoning about distributed failure modes is a cycle not spent on product logic. The productivity impact is real and measurable, though rarely tracked.

The Infrastructure Mirage

Microservices advocates promised infrastructure efficiency: scale only the components that need it, use the right technology for each job, deploy independently. The reality is more complicated. Distributed systems require orchestration, service discovery, load balancing, circuit breakers, observability, and eventual consistency handling. Each of these is a non-trivial engineering concern.

The infrastructure overhead isn't just operational — it's developmental. Teams need expertise in distributed systems patterns, network reliability, data consistency models, and deployment coordination. This expertise is expensive and scarce. When every team needs distributed systems engineers, you've created a staffing bottleneck that constrains the entire organization.

The Prime Video case is instructive. Their serverless microservices architecture required orchestrating AWS Step Functions, Lambda functions, and multiple supporting services. Moving to a monolith eliminated this coordination overhead entirely. The 90% cost reduction wasn't just infrastructure savings — it was operational simplification that eliminated entire categories of complexity.

The Team Scaling Fallacy

small teams owning discrete services, Conway's Law working in your favor. The reality is often the opposite. Service boundaries that made sense for team structure become mismatched as organizations evolve. Teams merge. Products pivot. Services that were independent become tightly coupled. The architecture that was supposed to enable organizational flexibility becomes an obstacle to it.

The "two-pizza team" ideal assumes stable, autonomous services with clear boundaries. Most real-world systems don't have boundaries that clean. Business concepts cross-cut services. Transactions span multiple domains. The microservices architecture encodes organizational assumptions that become obsolete as the business changes.

This creates architectural drag. Refactoring across service boundaries requires coordination, versioning strategies, and migration windows. Changes that would be straightforward in a monolith require weeks of planning in microservices. The architecture that was supposed to enable speed becomes a constraint on it.

When Microservices Actually Make Sense

This isn't an argument against all distributed architectures. There are situations where microservices are genuinely the right choice:

True scale requirements: When individual components need to scale independently by orders of magnitude — think Netflix's streaming infrastructure, where the edge serving layer scales very differently than the content recommendation system. Not "we might need to scale someday" — actual, current, significant scale differences.

Genuine organizational independence: When teams are truly autonomous with separate deployment schedules, separate roadmaps, and minimal cross-dependencies. This requires organizational structure that most companies don't have.

Technology diversity requirements: When different parts of the system genuinely need different technology stacks — GPU-intensive ML inference alongside I/O-bound web serving, for example. This is rarer than teams pretend.

For the typical application — tens of developers, standard web serving patterns, moderate scale — these conditions don't apply. The microservices overhead is pure cost with no compensating benefit.

The Monolith Alternative

Monoliths have become a dirty word, but modern monoliths aren't the hairball nightmares of the 2000s. A well-architected monolith uses modular code organization, clear internal boundaries, and independent deployability of subsystems. The difference isn't architectural sloppiness — it's that the boundaries are code boundaries, not network boundaries.

This matters because code boundaries are cheaper to cross than network boundaries. Refactoring is a IDE operation, not a service migration. Testing is a single test suite, not integration across services. Debugging is a single stack trace, not distributed tracing across multiple systems.

The Prime Video team didn't abandon modularity — they moved it from the infrastructure layer to the code layer. The result was simpler, cheaper, and faster. This is the pattern emerging across the industry: modular monoliths that preserve organizational flexibility without the distributed systems overhead.

The Engineering Velocity Reality

Engineering velocity isn't about lines of code. It's about the time from idea to production, the confidence to make changes, and the cognitive load required to understand the system. Microservices slow all three.

Time to production expands because changes require coordination across services. Confidence drops because understanding the full impact of changes requires reasoning about distributed interactions. Cognitive load increases because engineers need to hold system-wide complexity in working memory.

The organizations that have reversed course — Amazon Prime Video, Segment's monolith migration, various startups that quietly abandoned microservices — report the same pattern: engineering velocity improved dramatically after consolidation. Not because the code got simpler — because the system got simpler.

The Honest Assessment

Most organizations adopted microservices because they seemed like the right choice for serious engineering, not because they had specific problems that microservices solved. The architecture became a status marker — real engineering teams build microservices. This was always cargo cult reasoning, and the consequences are now visible in delayed projects, frustrated teams, and migrations back to simpler architectures.

The microservices backlash isn't a pendulum swing to the opposite extreme. It's a recognition that architecture should follow requirements, not precede them. The right architecture is the one that solves your actual problems with acceptable costs. For most organizations, most of the time, that isn't microservices.

Before you default to microservices, ask: what specific problem are we solving? What scale do we actually have? What coordination costs are we accepting? If the answers are vague, you don't have a microservices problem. You have an architecture-as-fashion problem.

Start with a monolith. Extract services only when you have specific, measurable reasons to. The complexity you avoid is complexity you don't have to manage. And managing complexity is what engineers do — so less complexity means more capacity for everything else.