🟢 Junior Level

Strangler Fig is a pattern for gradual migration from a monolith to microservices.

Nature analogy: a fig tree grows around another tree, gradually replacing it until the original tree disappears.

Monolith: [==============]

Step 1:  [==========] + [User Service]
Step 2:  [======] + [User Service] + [Order Service]
Step 3:  [==] + [User Service] + [Order Service] + [Payment Service]
Step 4:  [User Service] + [Order Service] + [Payment Service]

---

🟡 Middle Level

How it works

1. API Gateway in front of the monolith:

Client → API Gateway → Monolith (by default)
                     → New service (if exists)

2. Gradual migration:

1. Extract User functionality → User Service
2. Route /api/users → User Service
3. Extract Order → Order Service
4. Route /api/orders → Order Service
5. Continue until the monolith is gone

Common mistakes

1. Big bang migration:

   2 years of development → all at once → high risk
   Strangler: low risk, step-by-step migration
   

---

🔴 Senior Level

Dual write pattern

When migrating data:
1. Write to monolith AND to the new DB
2. Read from the new DB
3. Compare data
4. Remove writes to the monolith

// Dual write problem: if writing to the old system succeeds but writing to the new one fails, // data becomes out of sync. Solution: Outbox pattern or CDC.

Production Experience

Feature flags:

@Value("${feature-flag.use-new-user-service:false}")
private boolean useNewUserService;

// Feature flags are a separate pattern, but they help with Strangler Fig:
// you can switch traffic to the new system without a deployment.

@GetMapping("/users/{id}")
public User getUser(@PathVariable Long id) {
    if (useNewUserService) {
        return newUserService.getUser(id);
    }
    return monolith.getUser(id);
}

Best Practices

✅ API Gateway with routing
✅ Feature flags
✅ Dual write when migrating data
✅ Step-by-step migration

❌ Big bang migration
❌ Without feature flags
❌ Without monitoring during migration

---

🎯 Interview Cheat Sheet

Must know:

• Strangler Fig — gradual migration from monolith to microservices
• API Gateway in front of the monolith — routes to new services or the monolith
• Step-by-step migration: extract functionality → route to new service → repeat
• Dual write pattern when migrating data — write to old and new DB
• Feature flags — switch traffic without deployment
• Outbox pattern or CDC solve the dual write problem (data desynchronization)
• Big bang migration = 2 years of development → all at once → high risk

Frequent follow-up questions:

• What is the dual write problem? Write to the old system succeeds, write to the new one fails, data becomes out of sync — solution: Outbox or CDC.
• Why feature flags? You can switch traffic to the new system without deployment, quick rollback.
• How to monitor migration? Compare responses from old and new systems, error metrics, latency.
• Migration order? Start with the least critical functionality, gradually move to core.

Red flags (NOT to say):

• “Big bang migration is faster” — no, higher risk, harder to roll back
• “Dual write without Outbox is fine” — no, data becomes out of sync
• “Feature flags are not needed, can just deploy” — without feature flags, rollback = new deployment
• “Migration without monitoring” — no, you need to see problems in real time

Related topics:

• [[14. What problems arise when using shared database]]
• [[13. What is Database per Service pattern]]
• [[9. What is API Gateway and what problems does it solve]]
• [[3. How to implement distributed transactions in microservices]]
• [[26. What tools are used for microservices orchestration]]