Microservices vs Monolith: The Only Question That Matters

The microservices debate is mostly people arguing past each other, because they are describing different companies.

A team of six does not have the problems microservices solve. A team of three hundred does not have the option of ignoring them. Both sides are right about their own situation and wrong about everyone else's.

So here is the honest version: what each architecture actually costs, the one question that decides between them, and why "composable" is a useful idea buried under a lot of marketing.

Start here: microservices are an organizational solution

This is the thing that gets missed, and it explains most of the bad decisions.

Microservices do not make your software faster, simpler, or more reliable. On every one of those dimensions, a well-built monolith wins. One deployment, one log, one database, no network between your function calls.

What microservices buy is team independence. They let forty engineers ship without coordinating every release, because each team owns a service and deploys on its own schedule.

That is the whole value proposition. Everything else is a cost you pay to get it.

Which leads to the useful test: if your teams are not blocking each other, you are paying for a solution to a problem you do not have.

It is worth sitting with that, because it inverts how the decision usually gets made. Architecture is normally argued on technical merits, scalability, resilience, clean separation of concerns. Those arguments are mostly a proxy.

The real question is about people: how many of them, working on what, and where do they collide? Answer that honestly and the architecture mostly picks itself.

The monolith, and why it is still the right default

A monolith is one application, one deployment, one codebase. It is deeply unfashionable and usually correct.

The advantages are real and get undersold.

• You can debug it. A stack trace goes end to end. No correlation IDs, no distributed tracing, no reconstructing what happened across six services.
• Transactions just work. One database means real ACID guarantees, rather than eventual consistency and a saga pattern you now have to maintain.
• Refactoring is cheap. Changing an interface is a compiler problem, not a coordinated release across four teams.
• One thing to run. No service mesh, no orchestration layer, no distributed config, no on-call rotation per service.

The real weakness is not technical. It is that above a certain team size, everyone is committing to the same codebase and coordination costs explode.

Note the phrasing: team size. Not traffic, not code volume. A monolith serving millions of users is completely normal. A monolith with eighty engineers fighting over releases is the actual problem.

Microservices, and what they really cost

Microservices split the application into independently deployable services, each owning its own data.

Done well, this genuinely works: teams ship independently, services scale independently, and one failure does not take down everything.

But the costs are systematically underestimated, because most of them do not appear until you are already committed.

• Every function call becomes a network call. Which means latency, retries, timeouts, and partial failure, none of which existed before.
• Distributed transactions. The thing that was one database write is now a coordination problem with no clean solution.
• Debugging gets genuinely hard. A bug now spans services, and you cannot see it without tracing infrastructure you have to build and maintain.
• Operational overhead multiplies. Twelve services means twelve deployments, twelve dashboards, twelve sets of alerts.
• Testing becomes a project. Integration testing across a distributed system is dramatically harder than running the monolith's test suite.

The pattern I have seen most often: a small team adopts microservices for a scale they anticipate but do not have, and spends the next year on infrastructure instead of product.

They did not get the benefit, because they never had the coordination problem. They paid the entire cost anyway.

The decision, in one table

Strip away the ideology and the choice comes down to a few honest questions.

If you are in the left column and building the right one, stop.

The single strongest signal is the "domain clarity" row, and it is the one people skip. Splitting a domain you do not understand yet gives you distributed boundaries in the wrong places, and moving a boundary across services is enormously harder than moving one inside a codebase.

You have to understand the domain before you can split it. Which means the monolith is not just acceptable early, it is how you learn where the seams actually are.

The migration path that works

If you genuinely need to split, do not rewrite. Rewrites fail.

The approach that works is incremental: keep the monolith running and peel services off one at a time.

1. Find a real seam. Look for a part of the domain with few dependencies and clear boundaries. Something on the edge, not in the middle.
2. Extract one service. Just one. Route traffic to it while the monolith still handles everything else.
3. Run both, briefly. Verify the new service handles real load correctly, with the monolith as the fallback.
4. Cut over and delete. Remove the old code path. If you skip this step, you have added complexity without removing any.
5. Stop when the pain stops. This is the step nobody talks about.

That last one matters. The goal is not "microservices." The goal is teams that are not blocking each other.

If extracting three services solves that, you are done. Extracting twelve more because the architecture diagram feels incomplete is how you end up with a distributed monolith: all the operational cost, none of the independence.

The modular monolith: the option nobody mentions

The debate is usually framed as two choices. There is a third, and for most companies it is the right one.

A modular monolith is one deployable application with hard internal boundaries. Modules talk through defined interfaces rather than reaching into each other's data. It ships as one unit.

You get the operational simplicity of a monolith: one deploy, one stack trace, real transactions. And you get most of the design discipline of microservices, because the boundaries are explicit and enforced.

Crucially, it is also the cheapest way to find out where your seams actually are. If a module boundary turns out to be wrong, you move it in an afternoon. Discovering the same mistake across two services takes a quarter.

And when you genuinely do need to split, a well-modularized monolith is trivial to split. The boundaries already exist; you are just moving one across a network.

This is the path I recommend most often, and it is unpopular for a bad reason: it is not exciting. There is no conference talk in "we drew clear lines inside one codebase."

The distributed monolith: the worst outcome

There is a failure mode worse than either architecture, and teams back into it without noticing.

A distributed monolith is microservices that cannot deploy independently. Service A needs a matching change in Service B, so releases have to be coordinated anyway.

You now have every cost of distribution, network calls, partial failure, tracing, twelve deployments, and none of the benefit, because your teams are still blocked on each other.

The tell is simple: if shipping a feature requires releasing more than one service together, you built this.

It usually happens because the split followed the org chart or the database tables rather than the domain. Boundaries drawn in the wrong place force chatter across them, and chatter is coupling.

This is the strongest practical argument for waiting until your domain is well understood. A premature split does not just cost you time. It produces the one architecture that is worse than both alternatives.

What "composable" actually means

Composable architecture is the current term of art, and underneath the marketing there is a real idea.

It is this: build capabilities with clean contracts so they can be recombined, and buy anything that is not your differentiator.

In practice that means your business logic is yours, and your authentication, payments, search, and email are probably somebody else's product. Not because you cannot build them, but because building them is how you spend two years not shipping the thing customers actually pay for.

The useful discipline is deciding what is genuinely core. Everything core, you own. Everything else, you integrate behind an interface you control, so you can swap it later.

The trap is that composable is often sold as an architecture. It is not. It is a buy-versus-build stance plus good interface hygiene, and you can practice it inside a monolith perfectly well.

A monolith with clean internal module boundaries and a few well-chosen vendors is composable. A pile of microservices with tangled dependencies is not.

The mistake underneath all of these

Almost every bad architecture decision I have watched came from the same place: choosing for the company you hope to become rather than the one you are.

The reasoning sounds responsible. We will have hundreds of engineers eventually, so let us build for that now. Better to do it right from the start.

But you are paying today's cost for tomorrow's benefit, and tomorrow is not guaranteed. Most companies that build for hypothetical scale never reach it, partly because the complexity slowed them down enough to matter.

The reverse mistake exists too, and it is rarer: a company that genuinely has eighty engineers deadlocked on one codebase, refusing to split because the monolith is simpler. At that point simplicity has become a story you are telling yourself.

Both errors come from optimizing for an abstraction instead of the actual pain in front of you.

Frequently asked questions

The bottom line

Microservices are an organizational solution, not a technical upgrade. They buy team independence and charge you in latency, distributed transactions, debugging difficulty, and operational overhead.

So default to the monolith. Split only when teams are genuinely blocking each other and your domain boundaries have stopped moving. When you do split, go incrementally, delete the old path, and stop the moment the coordination pain is gone.

Treat composable as a discipline rather than a destination: own your differentiator, buy the rest, keep the interfaces clean.

And choose for the company you are today. The one you hope to become will thank you for still being alive.

If you take one thing from this: the modular monolith is the answer far more often than the internet suggests, and it keeps every option open.

One last note: the hardest part of any architecture change is rarely the architecture. It is getting the organization to actually work the new way, which is a change management problem wearing a technical costume. Sequence your modernization audit and migration behind that reality.