Microservices became gospel between 2015 and 2020. But some teams are now discovering that going back to a well-architected monolith is the right move for their situation. I'm not shocked. Architecture should fit your constraints, not follow a trend.
When enthusiasm becomes burden
The microservices boom coincided with a moment when "just make it a separate service" became the default architectural answer. Teams built tiny services that didn't actually need to be deployed independently. They had tight coupling to sibling services. They spent more time on network round-trips than they would have on function calls. And then every service needed its own deployment pipeline, its own monitoring setup, its own on-call rotation. The operational overhead was real.
The monolith rediscovery
A well-designed monolith with clear module boundaries, strict rules about cross-module dependencies, and the ability to deploy the whole thing independently gives you most of the benefits of microservices without the network costs and complexity tax. DHH called it the Majestic Monolith. The Spring Framework team formalized it as Modulith. .NET has similar patterns. It's not a new idea, but it's finally okay to say it out loud again.
When microservices actually make sense
Microservices pay for themselves when your team is big enough that independent deployment meaningfully reduces coordination. When services genuinely need to scale differently, making shared infrastructure a liability. When regulation requires isolation that a monolith can't provide. These are real situations. They're just less common than the 2016-2020 evangelism made it sound.
How to migrate back
The migration is less dramatic than you might think. Identify which services talk to each other constantly (high coupling). Decide whether they're actually scaling independently or if that was theoretical. Figure out a clean consolidation boundary. Use the Strangler Fig pattern in reverse: gradually move functionality from services into the monolith, piece by piece, until you can retire the services. It's incremental, not a risky cutover.