How Monoliths Evolve Into Microservices (Without a Big Rewrite)

How Monoliths Evolve Into Microservices

The worst way to split a monolith is a big-bang rewrite. You freeze the product, rewrite everything, and ship six months later. The product dies while you rewrite.

The Real Way: Strangler Fig

The strangler fig pattern: pick one piece of the monolith, extract it into a service, route traffic to it, and leave the rest alone. Repeat for the next piece.

Step 1: Identify a Bounded Context

Pick a feature with clear boundaries. Auth, payments, or notifications are good because they are self-contained. Pick something stable, not the part changing every week.

Step 2: Extract the Service

Move the code into a new repo or folder. Give it its own database (do not share with the monolith). Sync the data with events or a one-time migration.

Step 3: Route Traffic

In your API gateway or load balancer, route requests for that feature to the new service. Everything else still goes to the monolith. Ship this and watch.

Step 4: Delete the Old Code

Once the new service handles the traffic, delete the old code from the monolith. The monolith shrinks.

Step 5: Repeat

Pick the next piece. Extract, route, delete. Each step is small, shippable, and reversible.

Why This Works

You never freeze the product. Each step ships independently. If the new service has issues, you can roll back to the monolith. Risk is contained.

When to Stop

You do not need to split everything. Some parts are fine in the monolith. Stop when the remaining monolith is maintainable and the split services cover the parts that needed independence.

The Takeaway

Split a monolith into microservices using the strangler fig pattern: extract one bounded context at a time, route traffic, and delete the old code. Each step is shippable and reversible. Never do a big-bang rewrite.