There is a reversal happening in backend architecture, and almost nobody is announcing it. Teams that spent the late 2010s splitting their systems into dozens of microservices are now merging them back into larger deployable units. Not because microservices failed as an idea, but because most organisations adopted them at a scale where the costs outweighed the benefits. The interesting part is how quiet it is. Nobody writes a triumphant blog post titled "we deleted 60 services". They just do it, and the on-call rota gets calmer.
If you are running more services than engineers, this post is for you.
The evidence is not anecdotal any more
The most famous data point came from inside Amazon itself. The Prime Video team rebuilt its audio and video monitoring service from a distributed, serverless design into a single process, and reported infrastructure cost reductions of over 90% along with better scaling headroom. As former AWS VP Adrian Cockcroft pointed out in his response, this was really a refactor of an over-decomposed workload, which is precisely the lesson: decomposition itself has a price.
Segment got there earlier. The team collapsed more than 140 services back into a single application after three full-time engineers ended up spending most of their week keeping the estate alive rather than shipping features. After consolidating, test runs dropped from an hour to milliseconds and library improvements shipped 46 times in a year, up from 32.
Even Google has weighed in. A 2023 paper from Google engineers argues that microservices conflate logical code boundaries with physical deployment boundaries, and shows a prototype that cuts latency by up to 15 times and cost by up to 9 times by writing the application as one logical unit and letting a runtime decide how to distribute it.
Why the sums stopped adding up
Every service boundary you draw converts a function call into a network call. That buys you independent deployment and scaling, and it charges you serialisation overhead, retry logic, distributed tracing, versioned contracts, and a debugging experience that spans six dashboards. For a team of 300 engineers, that trade often pays. For a team of 12 running 40 services, it rarely does.
The hidden cost is cognitive, not computational. When a checkout bug requires reading logs across five services, your mean time to resolution is set by how quickly one person can rebuild the whole picture in their head. Consolidation shrinks that picture.
The chart above is illustrative rather than measured, but it matches what the case studies describe: consolidation moves hours from firefighting and pipeline upkeep back into feature work. Source: Twilio Segment.
Consolidation does not mean going backwards
The destination is rarely the tangled monolith of 2012. Most teams land on a modular monolith: one deployable unit, internally split into modules with enforced boundaries. Shopify has run one of the largest Rails codebases in the world this way, organising code around business domains with strict interfaces between components while keeping a single deployment.
You keep the discipline microservices forced on you, clear ownership, explicit contracts, domain-shaped boundaries, and you drop the network tax. Extraction remains available later, and it is far easier to split a well-modularised codebase than to merge a distributed mess. Getting those boundaries right is the hard part, and it is exactly the kind of decision worth pressure-testing with people who have done it before, which is where an experienced backend scaling and reliability partner earns its fee.
FAQ
Should we consolidate our microservices?
If your service count exceeds your engineer count, deployments require choreography, or debugging routinely crosses more than three services, consolidation will probably pay for itself. If separate teams genuinely need to deploy and scale independently, keep those boundaries.
Is a modular monolith just a monolith with extra steps?
No. The difference is enforced module boundaries, checked in CI, so teams cannot reach into each other's internals. You get microservice discipline with in-process speed and one pipeline.
Do microservices still make sense anywhere?
Yes. Workloads with genuinely different scaling profiles, isolation requirements, or large independent teams still justify separate services. The correction is about defaults, not dogma.
A five-step consolidation checklist
1. Inventory every service, its owner, its deployment frequency, and its real traffic.
2. Flag services that always deploy together; they are one module wearing several trench coats.
3. Merge the chattiest pair first and measure latency, cost, and incident volume for a month.
4. Enforce module boundaries in CI as you fold services in, so the monolith stays modular.
5. Keep genuinely independent workloads separate, and write down why.
If your team is spending more time operating services than building the product, BeyondPixl Studio runs architecture reviews that map your service estate, identify consolidation candidates, and leave you with a sequenced migration plan. Book a scaling and reliability review and get the first consolidation target identified within two weeks.