Monolith vs Microservices: An Honest Decision Guide

A nine-person team runs a grocery-delivery startup on a single web application. The CTO returns from a conference and announces that the platform will be split into microservices by quarter end. Six months later the team owns fourteen repositories, a flaky staging environment that nobody can fully run on a laptop, and a feature that used to be one pull request is now four. Was the split wrong? Not necessarily. It was never examined. This lesson gives you the tools to examine it.

Three shapes, defined by what you deploy

Forget lines of code. The useful definition is how many things you release and run separately.

• Monolith: one deployable unit. Everything (catalogue, cart, payments, delivery slots) ships together and usually shares one database. A monolith can be well structured or a tangle; "monolith" describes deployment, not quality.
• Modular monolith: still one deployable unit, but with enforced internal boundaries. Modules expose a small public interface, never reach into each other's tables, and could be extracted later with moderate effort.
• Microservices: several independently deployable services, each owning its own data, communicating over a network. Independence is the point: a service can be changed, released and scaled without coordinating a release of the others.

What the network takes from you

Inside one process, calling cartService.total(cartId) either returns or throws, takes microseconds and cannot be half-delivered. Across a network the same call can time out after the other side already acted, return slowly, or fail because a router somewhere restarted. You also lose transactions that span the call (the topic of the last lesson). The cheapest way to feel this is arithmetic: if a request must pass through several services in a row, their availabilities multiply.

# Availability of a request that must touch every service in a chain.
per_service = 0.999  # 99.9% each

for hops in (1, 3, 6, 10):
    chain = per_service ** hops
    downtime_min = (1 - chain) * 30 * 24 * 60  # minutes in a 30-day month
    print(f"{hops:>2} services in the call path -> {chain * 100:.2f}% available, "
          f"about {downtime_min:.0f} min/month unavailable")

 1 services in the call path -> 99.90% available, about 43 min/month unavailable
 3 services in the call path -> 99.70% available, about 129 min/month unavailable
 6 services in the call path -> 99.40% available, about 259 min/month unavailable
10 services in the call path -> 99.00% available, about 430 min/month unavailable

The model is simplified: it assumes failures are independent and that every service is required for the request to succeed. Real systems soften this with timeouts, fallbacks and caching, and they also make it worse with retries and shared dependencies. But the direction is reliable. Every synchronous hop you add is a place for the request to fail, and you must design for it on purpose.

What services genuinely buy you

There are real benefits, and each one depends on something you have to bring yourself.

Notice that most rows are about people and process more than about code. That is why the guidance below keeps returning to team size and delivery maturity. If you want the capacity side of the story, scalability and load balancing shows that a monolith behind a load balancer scales further than many people assume.

A checklist to run before you split

Answer these honestly, in writing, with the team. Each "no" in the first group is a reason to wait; each "yes" in the second group is a reason to consider splitting something specific rather than everything.

READINESS (all should be YES before splitting)
[ ] Can we deploy the monolith to production on demand, safely, in minutes?
[ ] Do we have automated tests that catch breaking changes?
[ ] Can we trace one request across components (logs with a request id)?
[ ] Do we know our domain well enough to name the seams?
[ ] Is someone on call who can debug a distributed failure?

PRESSURE (YES here points at WHICH piece to extract)
[ ] Do two or more teams collide in the same module every week?
[ ] Does one component need 20x the capacity of the rest?
[ ] Does one component need a different release cadence or compliance scope?
[ ] Is one component's failure currently taking down unrelated features?

DECISION RULE
No pressure items      -> stay a (modular) monolith.
Pressure, not ready    -> fix the readiness gaps first.
Pressure and ready     -> extract ONE service, run it for a quarter, then decide.

Common mistakes and the symptoms they cause

• Splitting by technical layer (a UI service, a business-logic service, a database service). Symptom: every feature needs changes in all of them, so deploys are coupled anyway.
• Splitting before the domain is understood. Symptom: boundaries move every month, and each move means rewriting APIs and migrating data between services.
• A shared database. Symptom: a column rename in one service breaks three others at runtime, and nobody can tell which code reads which table. You have a distributed monolith.
• Skipping the operational basics. Symptom: an outage page reads "something is slow" and nobody can say which of twelve services is responsible. Centralised logs and tracing come before the split, not after.
• Too many tiny services. Symptom: a team of nine owns fourteen deployables, and onboarding takes weeks because understanding one feature means reading five repositories.

How this shows up in real projects and interviews

System design interviews reward candidates who state a default and defend it: start with a modular monolith, extract services when a specific pressure appears, and name that pressure. Saying "microservices" as an automatic answer is a weaker signal than explaining what you would give up. On real teams, the useful skill is often migrating gradually: pick the module with the clearest boundary and heaviest pain, extract it behind its existing interface, and keep the rest alone. For more on practising this style of reasoning, see the system design interview guide.