The end of microservices, the start of something quieter
After a decade of distributed-by-default, the cost finally came due. Here is what is actually working in 2026.
The decade-long detour
For ten years we split everything. Every team got a repo. Every repo got a runtime. Every runtime got an SLO and a Slack channel. The architecture diagram metastasised until "service" stopped being a unit of design and became a unit of headcount.
The bill came due slowly, then all at once.
What is actually working
The teams I am consulting with in 2026 have, almost without exception, consolidated. Not back to a single monolith — that would be theatre. But to three to five well-bounded services, owned by named humans, deployed together when it makes sense.
Coordination is the work. Splitting code into more pieces does not reduce coordination — it relocates it from the IDE into the issue tracker.
The interesting question is not "monolith or microservices." It is "where is the unit of decision-making?"
Three patterns that survived
1. Modular monolith with hard internal boundaries. Same process, separate database schemas, mandatory pull-requests across module boundaries. Best for teams under thirty engineers.
2. Domain services with shared utility libraries. Three to five services. Each owned by a team. Auth, logging, and feature-flagging come from a shared library, not a service.
3. The "engine and frontends" pattern. One large engine (think: the part that does real work), several lightweight frontends. This is what most AI-native products are converging on.
What I tell teams now
If you are deciding between a monolith and microservices on a greenfield project in 2026, start with a modular monolith. The cost of splitting later is real but bounded. The cost of un-splitting is a cultural reckoning, and most organisations cannot bear it.
Filed in Microservices & Service Design
Tags: Architecture · Microservices · Modular monoliths