The architecture that was supposed to be the answer
Five years ago, you migrated to microservices. The story made sense at the time. Independent deployability, team autonomy, technology heterogeneity, scalability per service. Several conferences and a few books later, microservices were the default architectural choice for any new system worth taking seriously.
That story changed in 2024-2025. Amazon Prime Video's Video Quality Analysis team migrated from a distributed microservices architecture back to a single-process monolith, resulting in 90% infrastructure cost reduction plus improved scaling capabilities. That blog post didn't just go viral. It was the visible top of a much larger pattern. 42% of organizations that adopted microservices are now consolidating services back into larger deployable units.
The reasons are economic and operational. The microservices premium turned out to be larger than the autonomy benefit for many systems. Worth understanding before your next architectural decision.
Budget Approval Playbook
Inside a 5-step framework that won $500K of infrastructure budget in 14 days.
The math nobody put on the original slide
Microservices infrastructure costs are 3.75x to 6x higher than monoliths for equivalent functionality. At enterprise scale, monoliths cost roughly $15,000 per month versus microservices at $40,000-$65,000 per month. That cost difference comes from infrastructure overhead, the operations team needed to keep dozens of services running, the platform engineering required to make microservices coordination tolerable, and the coordination cost itself.
For teams that adopted microservices below those thresholds, the consolidation back to modular monoliths often produces significant savings without losing the architectural benefits people thought they were getting.
The decision framework that holds up
Five questions worth asking before any new system's architectural decision. Honest answers point you to one of three patterns: monolith, modular monolith, or microservices.
Question 1: How many developers will work on this system in 18 months?
Under 10: monolith. 10-50: modular monolith. Over 50: microservices may finally make sense.
The reasoning: distributed system complexity is a fixed cost per service. A team of 5 can't absorb that cost. A team of 200 can.
Question 2: How aggressively does this system need to scale specific components independently?
If you can't name a specific component that will see 10x the traffic of others, you don't need microservices for scale. Most systems can't actually name this; the "scaling story" was a feature of the original pitch but rarely the real driver.
Question 3: How different are the technology requirements per component?
If everything in your system speaks the same primary language and uses similar dependencies, microservices add complexity without benefit. If you have legitimately different requirements (Python ML pipeline alongside Java transaction processing, for example), there's a case for partitioning.
Question 4: How mature is your engineering culture and platform team?
Microservices require service discovery, monitoring, and sophisticated DevOps techniques that require an established engineering culture. Without a platform team that can operate this layer, microservices fail expensively. The pattern in failed microservices adoptions: the architecture demanded operational maturity the org didn't have.
Question 5: What does the modular monolith pattern give you that monolithic doesn't?
If the answer is meaningful, that's where to start. The modular monolith pattern (clear module boundaries, internal interfaces, separate codebases per domain inside a single deployable) gives most of the architectural benefits people wanted from microservices without the infrastructure cost.
What the 42% pattern actually looks like
The orgs consolidating back to monoliths aren't going back to spaghetti code. They're going to modular monoliths with clear domain boundaries, sometimes with a handful of specific microservices for the cases where the math actually justifies them.
The pattern: bring most services back to a shared deployable, retain microservices only for genuine scale or technology heterogeneity needs, simplify the operations layer, redirect the platform team toward feature work that was deferred during the microservices era.
The economic result, when done well, looks like Amazon Prime Video's 90% cost reduction. Not always that dramatic. Usually 40-70% infrastructure cost reduction with measurable improvements in deployment time and on-call burden.
How Logiciel fits this conversation
Most engineering leaders who reach out to us about architecture are five years into a microservices implementation and are starting to see the math. The infrastructure costs are higher than projected. The platform team is bigger than projected. The deployment coordination is harder than projected. They want to know if consolidation back to a modular monolith makes sense for their specific situation.
The work we do is the architectural review and migration. We score your system on the five questions, identify which services are genuinely justified versus which are accidental, and ship the consolidation alongside your team.
From Data Chaos to Data Confidence
Inside a 6-month plan that turned 47 fragile pipelines into 98.7% reliability.
Call to Action
The 30-minute move
Book a working session with a senior Logiciel engineer. Bring your current service inventory and infrastructure cost. We'll walk through the five questions against your specific architecture and tell you which services are candidates for consolidation.
Book the 30-minute architecture session →
Frequently Asked Questions
We're not seeing the 3.75-6x cost premium. Are we doing microservices right or wrong?
Depends on what counts. The cost premium includes infrastructure, platform engineering, on-call, and coordination time. If you're only counting cloud infrastructure, you're undercounting. Run the fully-loaded math.
Is the modular monolith pattern actually different from monolith?
Yes. Clear module boundaries, enforced internal interfaces, separate codebases per domain inside a single deployable. The discipline matters. A "modular monolith" without the discipline is just a monolith that's about to become spaghetti.
We're at 60 developers and microservices feel right. Should we reconsider?
Maybe not. The 50-developer threshold is approximate, not absolute. Other factors (technology heterogeneity, scale requirements, platform maturity) matter too. Run the five questions and see where you land.
Can we partially consolidate?
Almost always the right answer. Consolidate the services that were accidental. Keep the ones that have genuine reasons. The fully-monolithic and fully-microservices endpoints are usually the wrong picks; the answer is in between.
What's the biggest mistake in this decision?
Treating it as a one-way door. Microservices adoptions can be partially reversed. Modular monoliths can be partially decomposed when scale actually demands it. The architecture should evolve with the team and the system, not be locked in by a 2020 decision. --- Sources cited: - Amazon Prime Video: 90% cost reduction migrating back to monolith - Microservices 3.75-6x cost premium / 42% of orgs consolidating - Team-size threshold framework: <10 monolith, 50+ microservices
