The microservices rollback is really an operations story
Teams are not rejecting modularity. They are rejecting a deployment model that turns every feature into distributed operations overhead.
The microservices rollback is mostly an operations story. Teams are not discovering that modularity is bad. They are discovering that every new service is an operations obligation.
A service needs deployment, logs, metrics, alerts, dashboards, ownership, versioning, secrets, networking rules, local development support, test strategy, and incident response. If the business value of the split does not exceed that overhead, the architecture is a tax.
Small teams feel the tax first
Large platform organizations can hide the cost with internal tooling. Small and mid-size teams feel it immediately. One feature now touches five repositories. One bug requires three dashboards. One local test needs a zoo of dependencies. One API change becomes a release negotiation.
The useful compromise
The practical answer is not “monolith forever.” It is a modular monolith with strict internal boundaries, plus selective extraction when the reason is concrete: different scaling profile, separate reliability domain, separate compliance boundary, or independent team ownership that is actually mature.
Cost is a design input
Cloud bills, state-machine transitions, network traffic, observability volume, and engineering time are part of architecture. If a design looks clean on a diagram but makes the monthly bill and on-call rotation worse, it is not clean.
Operational rules
- Start with modules and interfaces before services.
- Extract only when the module has a clear independent runtime need.
- Measure latency, deployment friction, and incident cost after each split.
- Merge services when the operational cost has outgrown the benefit.
The better question is no longer “microservices or monolith?” It is “which boundary deserves to become physical?”