Strangler Pattern

After you break a monolith into microservices — covered in Microservices vs Monolith — you still have to move live traffic. You end up with multiple services, maybe even different databases.

Cool. But after you decide how many services you’re cutting the monolith into, real problems show up. One of them is migration.

What goes wrong if you cut over in one go

Let’s say you have a monolith talking to one database. Every small module inside it hits that same DB. Fine while it’s one app.

Now you’ve built microservices for those modules. Next step: move traffic from the monolith onto those services. Replace the modules.

Can you do that in one go?

No. Because what if you migrated the whole thing, something starts breaking, and you’ve already deleted the monolith path? Production is down. And your organization is losing a lot of money.

That’s the problem strangler is trying to fix. It’s a system migration pattern.

How strangler actually works

You have the monolith. You have the microservices.

Instead of dumping 100% traffic onto the new services at once, you start small. Let’s say only one microservice is ready — unit tested, integration tested, QA has done end-to-end. The other services might still be in progress. That’s normal. Team size and org decisions decide the pace.

For that one completed module, you move maybe 1% of live traffic to the microservice. If a million requests are coming for that module, 1% is tiny compared to that.

Then you watch it in production:

• Are DB updates fine?
• Are logs fine?
• Any errors on operations?

If it looks good, you bump it — 1% → 5% → 10% → 15% — and you keep going until it’s 100%. That’s how you fully migrate that module.

1% → microservice

Healthy at each step — raise the dial. Keep watching logs, errors, and DB.

Happy path

Traffic
  │
  ├─ 99% ──► Monolith (old module)
  │
  └─  1% ──► Microservice (new)
                 │
                 ▼
         watch logs / errors / DB
                 │
        ok? ──yes──► raise % (5 → 10 → 100)

“Strangler” literally means you’re strangling that part of the monolith. You’re killing it slowly by reducing the load it gets from live traffic, step by step.

What if it breaks midway

Let’s say 1% was fine, but at 5% it starts throwing errors.

You immediately cut traffic off the microservice and send it back to the monolith. Debug. Fix. Then try again from 1%, 5%, 10%…

That’s why this pattern exists. You get a rollback path without taking the whole product down.

1% looks fine

Same dial that raised traffic can slam it shut — that is the point of strangler.

Rollback path

1% OK ──► 5% ──► errors
                    │
                    ▼
         cut microservice to 0%
                    │
                    ▼
         Monolith 100% · fix · retry from 1%

When not to use this

Skip strangler if the module is tiny, unused, or you’re still in early development with no real users. Gradual traffic is overhead when there’s nothing to protect.

Also skip it if you can’t route a fraction of traffic for that path (no gateway, no feature flag, no shadow route). Without a dial, you’re back to big-bang whether you like the name or not.

Production pitfall

Dual-write / dual-read confusion. During the 1%–50% window, some requests hit the monolith and some hit the service. If both still write overlapping data — or caches disagree — you get “works for some users, broken for others.” Pick a clear source of truth per request, and make rollback mean all of that request’s traffic, not half the side effects left behind.

Short definition

Strangler is the way you move a monolith into microservices: kill the old path slowly by shifting traffic, not in one big bang.