Monolith vs microservices: the honest answer

The monolith vs microservices debate is one of the most asked questions in software architecture. It is also one of the most poorly answered. Most responses are either "microservices are the future" or "monoliths are simpler" — neither of which helps you decide.

Here is the honest answer, based on systems we have reviewed and teams we have worked with.

Start with a modular monolith

A modular monolith is a single deployable unit with clear internal module boundaries. Each module owns its data, exposes a clean interface, and does not reach into other modules' internals. It deploys as one unit but thinks as several.

This gives you 80% of the benefits of microservices (clear boundaries, team ownership, testability) with 20% of the complexity (no network calls between modules, no distributed tracing, no service mesh, no eventual consistency headaches).

app/  modules/    billing/      # owns its tables, API, logic    auth/         # owns its tables, API, logic    reporting/    # owns its tables, API, logic  shared/         # cross-cutting concerns only  app.js          # composition root // modules communicate via interfaces,// never via direct DB access

Extract services when you have a reason — not before

The transition from monolith to microservices should be driven by a specific, measurable need — not by a feeling that "we should be doing microservices." Valid reasons include:

A module that needs to scale independently (e.g., a report generator that spikes CPU while the rest of the system is I/O-bound). A module that needs a different technology stack (e.g., a data processing pipeline that benefits from Python while the rest is Node.js). A team that needs to deploy independently because their release cadence is 10x faster than the rest.

If none of these apply, extracting a service adds complexity without benefit. You now have network calls where there used to be function calls, distributed transactions where there used to be database transactions, and deployment coordination where there used to be a single deploy.

The cost of premature microservices

We have reviewed systems that split into 15 microservices with 4 developers. The result: every feature required changes across 3–4 services, deployment was a 2-hour coordination exercise, and local development required running 8 services on a laptop. Development velocity dropped by 60%.

When we consolidated them into a modular monolith with 3 extracted services (the ones that genuinely needed independence), velocity recovered within a month. The team shipped more, broke less, and slept better.

The decision framework

Ask yourself: Can your team deploy a monolith without pain? If yes, you do not need microservices. Is there a specific module with different scaling, technology, or deployment needs? Extract that one. Are you splitting because of team size? Consider a modular monolith with clear ownership boundaries first.

The right architecture is not the one that impresses on a slide. It is the one your team can build, deploy, and maintain without burning out.