Did Amazon Abandon Microservices?
When the Prime Video Engineering team published their article, it led to headlines like: “Amazon ditches microservices!” or “Microservices are dead, Prime Video moved to a monolith!”
Important: Amazon did not convert all of Prime Video to a monolith. Prime Video's main streaming platform, user accounts, catalog, and billing still run on microservices.
The change was made to only one component: the Video Quality Analysis (VQA) service.
Here is how the Video Quality Analysis service worked, its original architecture, and why it ran into issues at scale.
What the Video Quality Analysis (VQA) Service Did
Prime Video used an internal service called Video Quality Analysis (VQA) to monitor live and on-demand video streams:
What the VQA Tool Did:
- •Analyze video stream frames and audio in real time.
- •Detect audio and video defects such as blockiness, frozen frames, sync issues, or audio drops.
- •Alert operators immediately if an issue affected customer streams.
Because Prime Video streams thousands of live feeds and titles, this service had to process a large volume of video frames continuously.
The Old Architecture: Distributed and Serverless
The team initially built the service using AWS serverless components to build and deploy quickly:
│
▼
┌─────────────────────────────────────────────────────────────┐
│ AWS STEP FUNCTIONS (Orchestrator) │
│ (Managing thousands of state transitions) │
└──────────┬───────────────────────┬──────────────────────┬───┘
│ (Trigger) │ (Trigger) │ (Trigger)
▼ ▼ ▼
┌──────────────────────┐┌──────────────────────┐┌──────────────────────┐
│ AWS Lambda (Converter)││ AWS Lambda (Detector 1)││ AWS Lambda (Detector 2)│
└──────────┬───────────┘└──────────┬───────────┘└──────────┬───────────┘
│ (Upload Images) │ (Read/Write Images) │ (Read/Write Images)
└───────────┬───────────┴───────────┬──────────┘
▼ ▼
┌─────────────────────────────────────────────────────────────┐
│ AMAZON S3 BUCKET (Intermediate Storage) │
│ (Massive amount of intermediate image reads & writes) │
└─────────────────────────────────────────────────────────────┘
In the original architecture:
- AWS Step Functions: Coordinated the workflow and detection steps.
- AWS Lambda: Ran individual defect detection algorithms (video decoding, blockiness detector, freeze detector) as separate serverless functions.
- Amazon S3: Stored extracted video frames as temporary files so downstream Lambda functions could download and inspect them.
Too Much Communication and Intermediate Data Transfer
The issue was not that microservices or serverless were flawed. The issue was that this specific workload required heavy data transfer and constant communication between components.
Thousands of video frames were uploaded to S3 every second, and detector functions downloaded them back. This constant upload and download cycle added network latency and increased storage costs.
AWS Step Functions charges per state transition. Running multiple transitions for every single video frame hit account limits and caused costs to rise quickly.
// Old Architecture: Intermediate storage hops via S3
// Each detector ran in a separate AWS Lambda function
public class VideoDetectorLambda {
private final AmazonS3 s3Client;
public void handleRequest(S3Event event) {
// Step 1: Download video frames from S3 (High Network I/O & latency)
byte[] videoFrame = s3Client.getObject("vqa-frames-bucket", "stream-101/frame-45.jpg");
// Step 2: Run quality analysis algorithm
DefectResult result = analyzeDefect(videoFrame);
// Step 3: Write intermediate results back to S3 for next Step Function stage
s3Client.putObject("vqa-frames-bucket", "stream-101/defect-result.json", result.toJson());
}
}The Change: Moving Components into a Single Process
The team simplified the architecture by moving the separate components into a single application process.
│
▼ (Direct Stream into Container)
┌─────────────────────────────────────────────────────────────┐
│ AMAZON ECS CONTAINER (Single Process) │
│ ┌───────────────────────────────────────────────────────┐ │
│ │ SHARED IN-MEMORY BUFFER (RAM) │ │
│ │ (Video frames kept directly in memory) │ │
│ └───────┬───────────────────────┬───────────────────────┬─┘ │
│ │ (Memory Pointer) │ (Memory Pointer) │ │
│ ▼ ▼ ▼ │
│ ┌───────────────┐ ┌───────────────┐ ┌───────────────┐ │
│ │ Video Decoder │ │ Detector A │ │ Detector B │ │
│ └───────────────┘ └───────────────┘ └───────────────┘ │
└─────────────────────────────────────────────────────────────┘
│ (Only final aggregated results saved)
▼
[Event Notifications & Alerts]
Key Changes in the New Architecture:
- ✓In-Memory Data Transfer: Video frames were no longer written to S3. They stayed in container memory, accessible directly via memory pointers by all detector routines.
- ✓Step Functions Removed: Workflow orchestration moved inside the application code using standard method loops.
- ✓Amazon ECS & EC2 Deployment: The application was packaged into a container, deployed to Amazon ECS (Elastic Container Service), and scaled horizontally on EC2 instances.
// New Architecture: In-Memory Processing in a Single Process
// All detectors run together inside one container on Amazon ECS
public class VideoQualityAnalysisService {
private final List<VideoDefectDetector> detectors;
public void processStreamChunk(VideoChunk chunk) {
// Frames stay in shared RAM memory (No S3 calls, zero network hops)
byte[] frameBuffer = chunk.getRawBuffer();
// Detectors process the buffer directly in-memory
for (VideoDefectDetector detector : detectors) {
detector.analyze(frameBuffer);
}
// Only final aggregated defect alerts are sent to storage/alerts
}
}Result: 90%+ Infrastructure Cost Reduction
According to figures shared by the Prime Video engineering team:
Removing intermediate S3 reads and writes and Step Functions transitions let the application process frames in memory, reducing costs by over 90%.
• Removed account scaling limits from Step Functions.
• Reduced processing latency by removing network calls.
• Simplified horizontal scaling across thousands of video streams.
The Lesson: Match Architecture to the Workload
The takeaway here is not that monoliths are better than microservices or that serverless is bad.
“There is no single architecture that works best for every workload. The architecture should match the requirements of the workload.”
Microservices or Serverless Work Well When:
- • Components need independent deployments and release schedules.
- • Separate teams own distinct business domains.
- • Services pass small payloads over the network.
- • Traffic is bursty or event-driven (such as signup flows or payment webhooks).
A Single Process or Monolith Works Well When:
- • Heavy data transfer (such as video frames) occurs between stages.
- • Processing needs to happen directly in memory.
- • Frequent network calls between services create performance bottlenecks.
- • A closely related workload needs tight optimization.
Summary
The Prime Video team looked at the workload, found the main bottleneck, and moved the processing into a single process.
Did you find this breakdown helpful?
Share it with other developers discussing microservices, monoliths, and cloud architecture.