The Courage to Return to a Monolith: Lessons from Microservice Fatigue

1. What happens when we lose sight of why we split services

Microservices were originally a means of increasing team autonomy and allowing independent deployments. But when services outnumber team members, and a single feature change requires simultaneous pull requests across five services, those boundaries become a liability.

2. A concrete example: Prime Video’s 90% cost reduction

Consider a team that actually chose consolidation. A team at Amazon’s Prime Video built a monitoring tool that analyzed streaming video and audio quality in real time as a set of serverless microservices orchestrated through AWS Step Functions. In a case study published in 2023, the team reported that the orchestration layer itself became a bottleneck at scale.

The team responded by consolidating the distributed components into a single process, moving to EC2 and ECS with only a lightweight orchestration layer. It reported a 90% reduction in infrastructure costs. This was a specific monitoring workload, not a change to Prime Video as a whole. The lesson is not that microservices are bad and monoliths are good. It was a workload-specific design decision: the overhead of distributed orchestration was too high for frequent, low-latency processing of every stream in real time.

3. Signs that consolidation may be worth considering

• Calls between services are synchronous and tightly coupled, and few services can be deployed independently.
• Every incident investigation requires manually correlating logs from multiple services.
• Services outnumber team members, leaving each person responsible for everything across several services.
• As in the Prime Video example, the cost and latency of orchestration outweigh the flexibility that splitting services was supposed to deliver.

4. Consolidation is a design decision

Bringing services back together does not mean that adopting microservices was a failure. It can be a sound design decision: recognizing that the granularity does not fit the actual team, deployment frequency, or workload, and adjusting it to an operationally sustainable level. As the Prime Video example illustrates, this often means reassessing individual components, rather than reversing the entire architecture. A practical starting point is to ask, component by component, whether the cost of separation now exceeds its benefits.