How does the strangler fig pattern let you migrate a monolith to microservices incrementally?

#The problem with big-bang rewrites

The instinctive response to 'our monolith is unmanageable' is to schedule a rewrite: freeze the old system, build the new one properly this time, cut over on a target date. In practice this almost never goes to plan. The business does not pause while the rewrite is in flight, so requirements keep landing on the old system, the target keeps moving, and the rewrite has to hit a moving mark while starting further behind every month. Teams that attempt this frequently spend one to three years on a parallel system that never quite reaches feature parity, at which point the pressure to cancel the rewrite and 'just keep patching the old one' becomes very hard to resist.

#The pattern: a facade that gradually takes over

The strangler fig pattern avoids betting everything on one cutover. You place a routing layer -- a reverse proxy or API gateway -- in front of the monolith, and every request goes through it first. Initially, the proxy forwards 100% of traffic to the monolith, completely transparent to callers. When you extract a capability into a new service, you change the proxy's routing rules so requests for that capability go to the new service instead, while everything else keeps flowing to the monolith unchanged. You repeat this, one seam at a time, until the proxy is routing almost everything to new services and the monolith's remaining surface area is small enough to retire outright.

#The typical migration loop

1. Pick a bounded, well-understood capability at the edge of the monolith -- ideally something read-heavy with few write dependencies.
2. Build the new service against its own data store, backfilling historical data from the monolith's database.
3. Route a small percentage of traffic (or a specific tenant, or an internal-only flag) to the new service, while shadowing or diffing its responses against the monolith's to catch behavioral drift before it matters.
4. Ramp the routing percentage up once the new service has proven itself, watching error rates and latency the whole way.
5. Flip routing to 100%, remove the now-dead code path from the monolith, and repeat with the next capability.

#Why the database, not the proxy, is the hard part

Configuring routing rules is a day's work. What actually consumes months is the fact that, during the transition, both the monolith and the new service usually need access to overlapping data. If the new Orders service needs customer data that still lives in the monolith's database, you either let it read that database directly (coupling you were trying to remove), stand up a synchronization mechanism (dual-write, or change-data-capture streaming changes into the new service's own store), or accept a temporary API dependency back into the monolith. None of these are free, and picking wrong here is what turns a strangler fig migration into a multi-year slog.

🧠 Check your understanding
0/3 · 0/3 answered
1. What role does the proxy play in the strangler fig pattern?
It only exists during the final cutover stepIt replaces the monolith's databaseIt permanently splits traffic 50/50 between old and new systemsIt routes each request to either the monolith or a new service, and that routing can shift over time without callers noticing
2. What is typically the hardest part of a strangler fig migration in practice?
Choosing a name for the new serviceWriting the reverse proxy configurationDeciding which programming language to useThe shared database that both the monolith and the new service need during the transition
3. Why is the strangler fig pattern generally preferred over a full rewrite-and-cutover migration?
It lets you ship value and de-risk continuously instead of betting the business on one big cutover after months or years of parallel developmentIt avoids the need for automated testsIt requires no changes to the monolith at allIt is always faster overall