Complexity is not a moat
There is a pattern in mid-stage engineering organizations: the service count grows, the architecture diagram gets more complex, and everyone assumes this complexity is valuable because it was expensive to build.
It is not. Complexity is a cost. Value is what the system enables.
The microservices trap
Microservices solve a specific problem: allowing large organizations to deploy and scale components independently. They do not solve the problem of unclear ownership, poor contracts, or teams that cannot ship without coordinating with three other teams.
When 47 services exist but every deployment requires a cross-team meeting, the architecture has not delivered its promise.
The right question is about decisions
Value shows up when the platform helps people make better decisions faster:
- Can an operator see system health without opening five dashboards?
- Can a product team ship a feature without understanding the deployment pipeline's internals?
- Can finance attribute cost to business outcomes, not just AWS accounts?
If the answer is no, adding more services will not help.
The consolidation pattern
The most valuable architecture work in many organizations is not building new services. It is:
- Merging services that share an owner and a deployment cycle
- Replacing custom integrations with standard contracts (APIs, events, queues)
- Building one good internal platform instead of letting each team build their own
The goal is not fewer services or more services. The goal is a system where the people who use it can explain what it does and why.