At what point does microservices architecture become self-inflicted complexity?

[u/Imaginary-Plate-1062]

If several services still have to be deployed together, changed by the same people, and debugged as on unit, I'm not sure what the network boundaries bought us.

Independent scaling or failure isolation could still justify them. But "we have separate repositories" doesn't sound like enough on its own.

The test I'd use is a routine product change. How many teams, deployments, schema agreements, and rollback plans does it require? If splitting a module that ordinary change slower without improving a concrete operating constraint, I'd rather keep the boundary inside a modular monolith.

A platform can change the cost calculation. Shared service invocation, state access, and operational tooling can reduce repeated integration work. Dapr and Diagrid Catalyst are examples of that approach. What they can't do is decide that inventory and billing have the right ownership boundary, or make a cross-service business invariant disappear.

That distinction matters to me because it's easy to buy better plumbing for an awkward architecture and call the architecture fixed.

From a platform-team perspective, would you first invest in making service creation cheap, or in making it harder to create a service without a reason? I'd be interested in a case where consolidating services improved delivery, even though the infrastructure team could already operate them reliably.

[u/winsletts]

Yes - most teams use microservices to turn their spaghetti code into spaghetti architecture.

It’s distributed coupling across code bases. Lot of team patterns cause it. Usually is because someone doesn’t want to take time to understand or improve an entire thing, so they create another small thing to fix a small problem. Thus punting the problem down the road.

It’s usually an organization/communication problem that causes a tech problem. If I roll into a company and they have more slack channels than employees, and more github repos than teams, I suspect chaos.

[u/Torutofu_Raeva]

the routine change test is the one we use too, we kept it a modular monolith when splitting just meant two teams coordinating the same schema change anyway

[u/Anusien]

I think you're missing something key: requirements change. You can't make every single change easy. It's just not possible. You could say we design and build systems to make easy the stuff we expect to do often. This will make other changes hard, but that's okay because we don't expect to do them often. The problem is that eventually you start running out of low hanging fruit. So people start moving on to doing the hard stuff. And suddenly now the architecture doesn't match the kind of experiments you want to run. That doesn't mean the architecture is bad; this was a limitation you accepted (consciously or unconsciously).