The Return of the Monolith: A Practical Rethink of Microservices
Over the last few years (around 2023–2025), many engineering teams have started to rethink their heavy use of microservices. While microservices promised scale, flexibility, and independent deployments, real-world experience showed a different side: more complexity, higher cloud costs, slower development, and harder operations.
This does not mean microservices are bad or obsolete. It means teams are becoming more practical and selective. Instead of following architecture trends blindly, companies are choosing what actually works for their size, workload, and team structure.
In my earlier blog post — Microservices and Monolithic: Understanding the Design Patterns
( https://itechnotes.abhishekdwivedi.in/microservices-and-monolithic-understanding-the-design-patterns/ ) — I explained the basics of both architectures, their pros and cons, and when each approach makes sense.
In this post, I focus on a growing pattern: moving from microservices back to a monolith or a modular monolith, and why it worked for several well-known teams.
Amazon Prime Video: Simplifying a Complex System (2023)
Amazon Prime Video built an internal system to monitor video quality in live streams. The first version used many serverless and microservice-style components like AWS Lambda, Step Functions, and S3.
What went wrong
- The system did not scale well and handled only a small part of the expected load.
- Too many moving parts added latency and made debugging difficult.
- Cloud costs became very high due to orchestration and data transfers.
What they changed
- The team merged the logic into a single monolithic application, while keeping most of the existing code.
What improved
- Infrastructure costs dropped by about 90%.
- Performance and scalability improved significantly.
- The system became much easier to operate.
Segment (Twilio): Fewer Services, Faster Teams
Segment grew its data platform into 140+ microservices, many of them built around individual integrations.
What went wrong
- Managing so many services and repositories became very expensive.
- Small library changes required redeploying many services.
- Developers spent more time fixing pipelines than building features.
What they changed
- They combined the system into a large modular monolith.
- Moved to a single codebase (monorepo) and a shared, reliable queue.
What improved
- Deployments became much faster.
- Developer productivity increased.
- Production incidents reduced noticeably.
InVision: Reducing Service Sprawl
InVision faced growing complexity as its product evolved. Over time, the system ended up with many services, databases, and dashboards.
What went wrong
- A relatively small team had to maintain too many services.
- Operational overhead increased.
- Product development slowed down.
What they changed
- The company consolidated many services into a more modular monolith, reducing the number of deployments.
What improved
- Easier system management.
- Lower operational effort.
- Better focus on product work instead of infrastructure.
Istio: A Monolith Inside an Open-Source System
Istio is a popular service mesh used with microservices. Ironically, its own control plane was originally built as multiple microservices.
What went wrong
- Installation and upgrades were complex.
- The benefits of splitting the control plane were limited.
- Maintenance became difficult for users and contributors.
What they changed
- The team merged the control plane into a single binary called Istiod, while keeping internal modules.
What improved
- Much simpler installation and upgrades.
- Better reliability.
- Easier adoption for users.
Why More Teams Are Choosing Simpler Architectures
Most companies still use microservices in some form. However, many have learned that:
- Microservices work best at very large scale with dedicated teams per service.
- For smaller teams or tightly connected logic, microservices can slow things down.
- A well-structured monolith or modular monolith can deliver features faster, cost less, and be easier to operate.
The main lesson is simple: architecture is a tool, not a rule. Start simple, split only when needed, and merge again if things become too complex.
As often advised in the industry:
Use a monolith until you have a real reason not to.
If your system feels expensive, slow to change, or hard to operate, it may be worth reconsidering whether all that distribution is actually helping.