Serverless vs. Monolith through the lens of the Prime Video case study｜艶雨
After reading the shocking record of cost reduction by AWS engineers, Prime Video cut costs 90% by deleting its serverless architecture. Then the post vanished., I was prompted to think about what constitutes the “correct answer” in modern system design, so I will organize the content here.
I’m skeptical about serverless, but I didn’t realize such an article had come out from within AWS.
Introduction: Why this topic attracted attention
In 2023, a blog post published by the Prime Video engineering team sparked a major debate in the tech community. The content detailed how, after migrating their video quality analysis system architecture from “serverless microservices” to a “monolith” (a single application), infrastructure costs were reduced by over 90%.
Although the official article can no longer be read because the original URL now redirects, it documented the unexpected pitfalls of serverless, which is often thought of as a “silver bullet.”
Previous architecture: Textbook serverless
Initially, what they built was a distributed design that followed AWS best practices.
-
AWS Step Functions was used to control the overall workflow.
-
AWS Lambda was used to execute individual processes such as video frame detection and quality analysis.
-
Intermediate data between each process was stored in Amazon S3.
This configuration seems to have made a lot of sense in the early stages of development. This is because each component could be developed independently, and scalability could be left to AWS.
Challenges faced: Reaching the limit at 5% of expected load
However, this “textbook” design hit a wall when they tried to start large-scale operations.
-
State transition costs: Step Functions state transitions (charged per action) became a non-negligible amount while processing massive numbers of video frames.
-
Data transfer overhead: The latency when exchanging large amounts of image data via S3, and the associated storage costs, ballooned.
-
Account limits: They reached limits such as the number of concurrent Lambda executions, and it turned out they could only handle about 5% of the target load.
They fell into an ironic situation where “as a result of separating components to make them loosely coupled, the communication costs between them ate up the overall performance and budget.”
New architecture: Integration into a single process
To solve this problem, they fundamentally re-examined the design. They reconfigured the distributed components into a single application running on Amazon ECS (Elastic Container Service).
The changes resulting from this modification can be summarized as follows.
By consolidating components into one, they were able to exchange data at high speeds within memory, bypassing expensive network communication and state management services.
Lessons learned from this case
This case is not about “serverless being bad,” but rather illustrates the importance of “selecting technology based on workload characteristics.”
For example, serverless may still be suitable for use cases like Web APIs that have low execution frequency and bursty access. However, for workloads that “continuously process large amounts of data” like this one, managing the infrastructure yourself (e.g., with ECS) and increasing in-process handling can sometimes be overwhelmingly advantageous in terms of both cost and performance.
Microservices and serverless are means to increase organizational scale and development independence, but it is necessary to always pay attention to whether they are becoming bottlenecks in the system.
Summary
The decision made by the Prime Video team can be said to be the result of calmly analyzing actual performance and costs, rather than sticking to trendy architectures.
When you are unsure about system design, pausing to ask yourself, “Is it really necessary to separate this component?” or “Can this be processed without going through the network?” might lead to unexpected optimization hints.
Reference Articles
For more details, please see here.
I also operate a learning site called “code learning hub” where you can learn by running the contents of technical books directly in your browser. If you like, please take a look here.
