How do you migrate a monolith to microservices using the strangler-fig pattern?

Question

Accepted Answer

The **strangler-fig pattern** migrates incrementally: you wrap the monolith with a routing layer, extract one capability at a time into a service, and redirect traffic to it — until the monolith is "strangled" away. There is **no big-bang rewrite**.

## How it works

```text
Step 1: route all traffic through a facade/proxy to the monolith
Step 2: extract ONE capability → new service
Step 3: route just that path to the new service
Step 4: repeat; delete that code from the monolith

Client ─▶ [ Proxy ] ─┬─▶ /orders  ─▶ NEW Orders service
                       └─▶ everything else ─▶ Monolith
```

## Choosing what to extract first

```text
✓ A bounded context with clear boundaries
✓ Something that needs independent scaling or deploys
✓ A part with few inbound dependencies (low risk)
✗ Don't start with the tangled core
```

## Handling shared data

The hard part is the database. Extract the service's tables, then break the shared-DB coupling using events or an anti-corruption layer, often via the **branch-by-abstraction** technique while both run.

## Trade-offs

```text
✓ Low risk — small, reversible steps, always shippable
✓ Value early, learn the seams as you go
✗ Slow; you run a hybrid system for a long time
✗ Temporary duplication and routing complexity
```

## Why it matters

Big-bang rewrites famously fail — they freeze feature work for months and ship a risky all-at-once cutover.

The strangler-fig keeps the system live and releasable the entire time, lets you stop or reprioritize at any point, and forces you to discover real service boundaries from the running system rather than guessing them up front.