The Great Architectural Pivot: Why Amazon Prime Video Ditched Microservices for a Monolith

As we wrap up our look back at the most defining tech shifts of 2023, one story stands head and shoulders above the rest. It’s a narrative that sent shockwaves through the DevOps community and sparked a heated debate that is still raging in engineering Slack channels today. We’re talking, of course, about Amazon Prime Video’s decision to ditch its microservices and serverless-heavy architecture in favor of a traditional monolith.

For years, we’ve been told that microservices are the promised land of scalability and that serverless is the ultimate destination for any modern application. But as the Prime Video team discovered, the "silver bullet" of microservices can sometimes turn into a self-inflicted wound. By reverting to a monolithic design, they didn't just fix their performance issues—they absolutely crushed their operational costs by 90%.

When Theory Hits the Hard Wall of Reality

In theory, the team’s original serverless architecture was a masterpiece of modern cloud-native design. It used AWS Step Functions for orchestration and AWS Lambda for individual tasks, which should have allowed every component to scale independently. However, theory and practice collided at just 5% of the intended scale. The team hit a hard limit that no amount of individual component optimization could fix.

As Joab Jackson noted in his coverage of the event, the IT world is famously cyclical. What is derided as "hopelessly archaic" one year—like the monolith—becomes the "next big thing" the next. The Prime Video team realized that by trying to be too modern, they had actually built a system that was too fragmented to perform.

The Astronomical Cost of Moving Data

The most eye-popping figure from this transition is the 90% reduction in operational costs. How does moving away from serverless save that much money? Rafal Gancarz broke down the numbers, pointing to a massive volume of read/write operations to S3 buckets. In the old microservices setup, intermediate data (like video frames being analyzed) had to be stored and retrieved constantly as it moved between services.

By consolidating all the business logic into a single application process, the team kept that data in the process memory. They swapped expensive AWS Step Function transitions and S3 storage hits for lightning-fast, in-memory data transfers. The new architecture runs on Amazon EC2 and ECS, distributed across different tasks to avoid vertical scaling limits while maintaining the efficiency of a unified process.

A "Zombie Architecture" or Just a Prototype?

The move didn't go unnoticed by the industry’s most vocal critics. David Heinemeier Hansson (DHH) didn't mince words, calling microservices a "zombie architecture" and a "siren song" for needlessly complicating systems. He argued that while Service-Oriented Architecture (SOA) makes sense at the scale of Amazon as a whole, pushing it into the internals of a single application is often a recipe for disaster.

However, Amazon CTO Dr. Werner Vogels offered a more nuanced perspective. He reminded us that "there are few one-way doors" in architecture. His rule of thumb is simple: every time you grow by an order of magnitude, you must revisit your architecture. For Prime Video, the monolith wasn't a step backward into the dark ages; it was the right tool for their current scale and specific use case.

Refactoring vs. Regression

Not everyone agrees that this was a "defeat" for microservices. Tech veteran Adrian Cockcroft suggested that the internet’s take on this was largely a "popular trigger meme." He argues that the Prime Video team followed a "Serverless First" path—building a quick prototype with Lambda and Step Functions to see what worked, then refactoring it into a high-efficiency, long-running containerized service once the requirements were clear.

In this view, what they built isn't a traditional, clunky monolith, but a highly optimized, horizontally scaled microservice that just happens to handle more than one task internally.

The Machete and the Fruit Salad

Perhaps the most grounded takeaway comes from the developer community's reaction. As one veteran sysadmin put it, "You don’t need a machete to make a fruit salad." The microservices craze has led many teams to bootstrap complex clusters and write hundreds of lines of configuration for tasks that could be handled by a simple script or a single process.

As Prime Video developer Marcin Kolny explained, moving to a single process simplified the orchestration logic and improved resilience. The lesson for the rest of us is clear: architecture should serve the product, not the other way around. Sometimes, going back to basics is the most innovative thing an engineering team can do.