Monolith vs Microservices: Why Amazon Split (and Prime Video Merged Back)

By Devang Pandya · Cloud Tech by Devang · Cloud • DevOps • AI — Made Simple

For about ten years, the loudest advice in software was: "Break your monolith into microservices." Then, in March 2023, a team inside Amazon, the company most famous for microservices, published a blog post saying they had moved one service back into a single process and cut its infrastructure cost by over 90%.

The internet went wild. "Microservices are dead!" "Monoliths are back!" Both reactions were wrong.

In this post I will explain, in simple English, what a monolith is, what microservices are, why Amazon split its monolith in the early 2000s, and what the Prime Video team actually did in 2023. Then I'll give you a clear answer for the interview question: "When would you choose a monolith over microservices?" I have spent 14+ years in cloud, DevOps and SRE, and I have seen teams win and lose with both styles. The style is never the point. Fit is.

1. First, the basics

What is a monolith?

A monolith is one application, built and deployed as one unit. All the features live in one codebase: login, product pages, cart, payments, emails. You build it once and deploy it once. Usually it talks to one main database.

Good things about a monolith:

• Simple to start. One repo, one build, one deploy.

• Fast calls. One part of the code calls another as a normal function call, in memory. No network.

• Easy to debug. One process, one log stream, one stack trace.

• Easy transactions. One database means one place to keep data consistent.

Problems as it grows:

• Everyone shares everything. A small change by one team needs a full redeploy of the whole app.

• Scaling is all-or-nothing. If only search is busy, you still scale the whole app.

• One bug can take everything down. A memory leak in one feature can crash the whole process.

• Unclear ownership. When 200 engineers touch one codebase, nobody owns anything fully.

What are microservices?

Microservices split the application into small, separate services. Each service does one job (for example orders, search, payments), owns its own data, and talks to others over the network through an API. Each service is owned by one team and can be deployed on its own.

Good things:

• Independent deploys. The payments team can ship without waiting for the search team.

• Independent scaling. Scale only the busy service.

• Smaller blast radius. If recommendations fail, checkout can still work.

• Clear ownership. One team, one service, end to end.

Costs:

• Network calls everywhere. Calls are slower and can fail. You need timeouts, retries and circuit breakers.

• Harder debugging. One user request may touch ten services. You need distributed tracing.

• Data is split. No single database transaction across services.

• More infrastructure. More pipelines, more monitoring, more things to secure and pay for.

Microservices are a trade. You pay in complexity to buy team independence and independent scaling.

2. Why Amazon split its monolith

In a 2006 interview with ACM Queue, Amazon's CTO Werner Vogels described how Amazon.com started as a monolithic application: a web server talking to a database on the back end. That application held all the business logic and display logic.

He explained that by 2001 it was clear the front-end application could not scale any more. The problem was not only performance. Many complex pieces were combined into one system, so it could not evolve. Parts that needed to scale on their own were tied to shared resources, and there was no isolation and no clear ownership. The shared databases were also hard to scale.

So Amazon moved to a service-oriented architecture. In Amazon's version, each service owns its data together with the business logic, and the only way in is through a published service interface. No other team may read the service's database directly. Over time this grew into hundreds of services. In that interview Vogels said that a single Amazon.com page could call more than 100 services to build it.

The team side mattered just as much as the technology. AWS describes Amazon's two-pizza teams: a team small enough to be fed by two pizzas, ideally fewer than 10 people, with single-threaded ownership of one service. Vogels' famous line from the same interview sums up the culture: "You build it, you run it." The team that writes the service also operates it.

Lesson for us: Amazon did not split its monolith because microservices were fashionable. (Vogels even said they did it before "service-oriented" was a buzzword.) They split because the monolith was blocking team speed and scaling, and they had the scale to justify the cost.

3. Prime Video: when distributed was the wrong choice

Now the 2023 story. It is about one specific tool, not all of Prime Video.

Prime Video's Video Quality Analysis (VQA) team owns a tool that checks video streams for quality problems, for example corrupted frames or audio and video going out of sync. They needed it to monitor thousands of concurrent streams, and to grow beyond that.

The original design

The first version was a distributed, serverless design:

• AWS Step Functions orchestrated the workflow.

• AWS Lambda functions ran the detectors.

• Amazon S3 stored video frames between the steps, so each component could pick them up.

On paper this looks perfect: serverless, independently scalable pieces.

What went wrong

According to the Prime Video Tech blog (Marcin Kolny, 22 March 2023):

• The design hit a hard scaling limit at around 5% of the expected load.

• Orchestration was the main bottleneck. The service did several state transitions for every second of every stream, so it quickly hit account limits. And Step Functions charges per state transition.

• Passing data between components was expensive. Every frame went into S3 and was read back out, which cost a lot at this volume.

The fix

The team moved all the components into a single process. Frames now moved in memory instead of through S3, and the orchestration logic ran inside the same instance. They deployed it on Amazon EC2 and Amazon ECS, and scaled by running more copies of the whole process.

The result, in their words: moving to a monolith cut infrastructure cost by over 90% and increased their ability to scale. They could handle thousands of streams with room to grow, and could also use EC2 compute savings plans to lower costs further.

What it does NOT mean

• It does not mean Amazon or Prime Video dropped microservices. This was one service.

• Some engineers argued the new design is really "one bigger microservice". It still runs as a separate service, just not split into tiny serverless steps. That is a fair point. The real lesson is about where you draw the boundaries.

• It does not mean serverless is bad. Serverless is great for spiky, event-driven work. It was a poor fit here because the workload moved huge amounts of data between steps at high, steady volume.

Lesson for us: if two parts of your system exchange large amounts of data all the time, putting a network (or S3) between them is expensive. Keep tightly connected, data-heavy steps together.

4. Putting the two stories side by side

Both teams made the right call for their problem. That's the whole point.

5. A simple decision guide

These are rules of thumb from my experience, not laws.

Start with a monolith (or a "modular monolith") when:

• You are a small team (one or two teams).

• The product is new and the boundaries are not clear yet.

• Parts of the system share a lot of data and change together.

• You want to move fast with few operational costs.

A modular monolith is a good middle path: one deployable app, but with clean internal modules and clear interfaces between them. If a module later needs to scale or move on its own, you can pull it out into a service.

Move to microservices when:

• Many teams are blocked by each other's releases.

• Different parts have very different scaling needs (for example search vs. account settings).

• You need a smaller blast radius for critical paths like checkout.

• You have the platform maturity: CI/CD, monitoring, tracing, on-call.

Warning signs you split too much:

• One user action needs a long chain of synchronous calls.

• Services always deploy together ("distributed monolith").

• Huge data moves between services on every request.

• Your cloud bill is dominated by data transfer and orchestration, not real work.

6. The example visuals

The service names in the Reel (Orders, Search, Payments, Catalog) are examples to show the idea of splitting an app. They are not an official list of Amazon's services. The Prime Video before/after diagram is a simplified version of the architecture the team described.

7. How to answer this in an interview

Question: "When would you choose a monolith over microservices?"

Strong answer:

"I'd start with a well-structured monolith when the team is small, the domain isn't clear yet, or the parts share a lot of data, because it's simpler, cheaper and faster to change. I'd split out services when teams are blocking each other or parts need to scale differently. Amazon split its monolith in the early 2000s for exactly those reasons, with two-pizza teams owning services. But the split has costs: network calls, data transfer, and operational overhead. Prime Video's video quality team showed that in 2023. Their Step Functions + Lambda + S3 design hit a limit at about 5% of the expected load, and putting it into one process on ECS cut infrastructure cost by over 90%. So I split when teams and scale need it, not by default."

Follow-ups to expect:

• What is a distributed monolith? Services that are split physically but still must deploy together. You get the costs of both styles and the benefits of neither.

• How do you split a monolith safely? The strangler fig pattern: put a router in front, move one feature at a time to a new service, and retire the old code path.

• How do services share data? Through APIs or events, not by reading each other's databases.

• How do you handle a transaction across services? Sagas: a series of local transactions with compensating actions if something fails.

Sources

• Marcin Kolny, Prime Video Tech, "Scaling up the Prime Video audio/video monitoring service and reducing costs by 90%" (22 Mar 2023). Archived copy: https://archive.is/h788m

• The New Stack, "Return of the Monolith: Amazon Dumps Microservices for Video Monitoring" (4 May 2023): https://thenewstack.io/return-of-the-monolith-amazon-dumps-microservices-for-video-monitoring/

• The Stack, "Prime Video service dumps microservices, cuts AWS bill 90%" (May 2023): https://www.thestack.technology/amazon-prime-video-microservices-monolith/

• ACM Queue, "A Conversation with Werner Vogels" (2006): monolith until 2001, service-oriented architecture, 100+ services per page, "you build it, you run it": https://queue.acm.org/detail.cfm?id=1142065

• AWS Executive Insights, "Powering Innovation and Speed with Amazon's Two-Pizza Teams": https://aws.amazon.com/executive-insights/content/amazon-two-pizza-team/

Preparing for a Cloud, DevOps or SRE interview? Book a Free 15-min Cloud & DevOps Interview Guidance Call with me: what to study, how to answer system-design and on-call questions, plus a CV and roadmap check 👉 https://topmate.io/cloudtechbydevang/2358399