Breaking up a monolith without a rewrite

Every monolith migration proposal starts the same way: we'll build the new system alongside the old one, then switch over. Almost none of them end that way. The old system keeps changing because the business keeps needing things, the new system chases a moving target, and eighteen months later you are maintaining two of everything.

The alternative is less satisfying and works far more often: never have a second system. Cut one seam at a time out of the one you have.

First, decide whether to do it at all

Microservices trade a code problem for an operations problem. You get independent deployment and scaling; you pay in network calls, distributed transactions, eventual consistency and a much harder debugging story.

That trade is worth it when you have a specific, named pain:

• One part of the system needs to scale independently — a report generator that pins CPU while the rest of the app idles.
• Teams are blocking each other on deploys, and release trains have become a scheduling problem.
• One component genuinely needs a different runtime — a Python ML service inside a Node application.
• A single failure mode takes down everything, and you need a blast radius.

The strangler pattern, concretely

Put a routing layer in front of the monolith — a proxy, a gateway, or just a reverse proxy rule. Every request goes through it. At first it forwards everything to the monolith and nothing has changed.

Then extract one capability. The new service handles a narrow set of routes; the router sends those to it and everything else to the monolith. Repeat. The monolith shrinks a little at a time, and at no point is there a big-bang cutover to get wrong.

The key property: you can stop at any point and still have a working system. Half-migrated is a stable state, not a crisis. That is the entire advantage over the rewrite.

Which seam to cut first

Not the most painful one. The first extraction is where you learn your deployment story, your observability story and your inter-service auth story — so pick something forgiving:

1. Low traffic, so mistakes are cheap.
2. Few dependencies on the rest of the domain — notifications, PDF generation, image processing, scheduled reports.
3. Clear input and output, so the contract is obvious.
4. Ideally asynchronous, so latency and retries are not user-visible.

Notifications are the canonical first service for exactly these reasons. It is dull, and that is the point — extract something dull while you are still learning, not your billing engine.

The hard part is always the data

Splitting code is a week. Splitting a database is the project. The moment two services share a table, you do not have two services — you have one system with extra steps and no transaction.

The sequence that works:

1. Stop writing to the shared table from the new service. Give it its own store, populated from events or a sync.
2. Move reads over gradually, comparing old and new results in production before trusting the new path.
3. Only then remove the old table access. Not before you have run both in parallel long enough to believe the numbers.

Expect eventual consistency and design for it explicitly. If the business genuinely cannot tolerate a few seconds of staleness somewhere, that is a strong signal the seam belongs inside one service, not across two.

What you need before the first extraction

• Distributed tracing. Without it, a bug that spans two services is unfindable. Add it before you need it.
• A deploy pipeline that can ship one service without shipping the others — otherwise you have kept every cost and gained no benefit.
• Contract tests between services, so an internal API change fails in CI instead of in production.
• An answer to service-to-service auth that is not "we're on the same network".

The version most teams should actually build

For a lot of products the right answer is not microservices at all — it is a well-structured monolith with the two genuinely independent things pulled out: the workload that needs to scale differently, and the workload that needs a different runtime.

Three services that map to real operational boundaries will serve you better than fifteen that map to an org chart. You can always cut another seam later. That is the whole point of doing it this way.

Frequently asked questions