Microservices Architecture: When It Helps and When It Hurts.

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.

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.

The team-size threshold matters: for teams under 10 developers, the monolith wins decisively. Microservices make sense at $10M+ annual revenue or 50+ developers, but below that, the coordination costs don't justify the distributed system complexity.

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.

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 →