Strangler Fig in Practice

The problem

The market loves turning useful patterns into pose.

Strangler fig suffers from that a lot.

People often talk about it as if it were just a fancy name for:

• breaking a monolith
• creating a microservice
• modernizing legacy

That is far too vague.

If you cannot explain where traffic goes, how the decision changes, and how the old system loses relevance safely, the pattern turns into theatre.

Mental model

Think about it like this:

strangler fig is an incremental replacement strategy mediated by routing

The central point is not “separate services.”

It is this:

• the flow enters through a controlled boundary
• that boundary decides whether it goes to the old side or the new side
• over time, more traffic goes to the new side
• the old side is gradually suffocated until almost nothing is left

The name matters less than that mechanic.

Breaking the problem down

Start from the boundary, not from the final diagram

Many migrations begin by trying to draw the entire future architecture up front.

With strangler fig, the useful question is simpler:

where can I intercept and redirect this flow without breaking everything?

That boundary may be:

• a gateway
• a facade
• an internal endpoint
• a queue
• an application layer that centralizes the use case

Without a controllable boundary, the pattern loses much of its value.

Move one flow at a time

You do not need to strangle the entire system in the first move.

Choose one small slice:

• one endpoint
• one use case
• one client group
• one event type

That makes it much clearer:

• what is being replaced
• what is still old
• how success will be measured

Keep coexistence between old and new intentional

For a while, both sides will coexist.

That period needs to be planned, not merely tolerated.

You need to know:

• who calls which side
• how behavior will be compared
• when the new side expands
• when the old side gets blocked

Without that discipline, the migration turns into confused duplication.

Do not use the strategy as an excuse to split things badly

Not every incremental extraction deserves to become a new service.

Sometimes the best use of strangler fig is:

• reorganizing a flow inside the same deploy
• creating a cleaner facade
• isolating behavior before even deciding the final topology

The pattern exists to reduce risk.

Not to manufacture unnecessary distribution.

Define how the old side will be retired

If you only know how to create the new side but not how the old side loses traffic and dies, the strategy is only half there.

A good question is:

what must be true before I can cut this flow away from legacy safely?

That answer needs to exist early.

Simple example

Imagine a monolith that handles signup and pricing.

The team wants to extract pricing.

Bad plan:

• create a new service
• send half the team to rewrite everything
• hope to integrate later

Better plan with strangler-fig logic:

1. create an internal facade for every pricing call
2. at first, that facade points to the old implementation
3. later, some flows start using the new implementation behind the same boundary
4. the team compares result, error, and latency
5. traffic expands gradually until the old implementation has little left
6. only at the end does the old path get removed

It is less Instagram-friendly.

It is also much more operable.

Common mistakes

• Treating strangler fig as an automatic synonym for microservice.
• Not having a clear routing boundary.
• Moving many flows at the same time and losing visibility.
• Creating the new side without a retirement strategy for the old side.
• Using the pattern name to hide lack of technical criteria.

How a senior thinks about it

Someone with more experience rarely asks:

“How do I apply strangler fig here?”

They ask something more like:

“What is the smallest controllable boundary that lets me move this behavior without betting the company on a single cutover?”

That way of thinking uses the pattern as a tool, not as architecture fantasy.

What the interviewer wants to see

In interviews, the evaluator wants to know whether you understand the mechanism, not whether you memorized a pattern name.

You level up when you:

• explain the role of the routing boundary
• talk about coexistence between old and new
• show that the migration is incremental and observable
• avoid automatically associating the pattern with microservices

A strong answer often sounds like this:

“I would use strangler-fig logic by creating a boundary where the flow can be redirected little by little. That lets me move small parts to the new implementation, compare behavior, expand with control, and retire legacy without a single hard cutover.”

Good strangler fig does not sell revolution. It buys safe transition.

When the pattern name is clearer than the migration plan, the conversation got worse.