3 min read

Strangler Fig Pattern

The Strangler Fig Pattern (often just called the Strangler Pattern) is a popular design pattern for migrating a legacy monolithic application to a modern microservices architecture.

1. The Metaphor

The pattern is named after the Strangler Fig tree found in rainforests.

  1. The fig starts as a seed in the upper branches of a host tree.
  2. It grows roots down to the ground and branches up to the sky.
  3. Over time, it gradually wraps around the host tree.
  4. Eventually, the host tree dies and rots away, leaving only the Strangler Fig standing in its place.

In software, the "Host Tree" is your Legacy Monolith, and the "Strangler Fig" is your new Microservices system.

2. The Problem: Big Bang Rewrite

Rewriting a massive legacy system from scratch (a "Big Bang" rewrite) is incredibly risky.

  • It takes years.
  • Business features freeze during the rewrite.
  • By the time the rewrite is done, requirements have changed.
  • The new system often has as many bugs as the old one.

3. How the Pattern Works

Instead of rewriting everything at once, you gradually replace specific functionalities with new services.

  1. Identify: Pick a specific piece of functionality in the legacy app (e.g., "User Profile" or "Order History").
  2. Transform: Build a new microservice that implements this functionality.
  3. Coexist: Deploy the new service alongside the legacy monolith.
  4. Intercept (The Facade): Put a proxy or load balancer (API Gateway) in front of both.
    • Route traffic for the new feature to the new service.
    • Route everything else to the legacy monolith.
  5. Eliminate: Once the new service is stable, remove that code from the monolith.
  6. Repeat: Pick the next feature and repeat until the monolith is gone.

4. Handling Data

Data is the hardest part.

  • Initial Phase: The new service might need to read/write to the legacy database to stay in sync.
  • Later Phase: You migrate the data to the new service's database and sync back to the legacy DB if needed.
  • Final Phase: The legacy DB is retired for that domain.

5. Anti-Corruption Layer (ACL)

When migrating, the new microservice often needs to communicate with the legacy system. However, the legacy system's data model is often messy or outdated.

  • The Risk: If the new service uses the legacy model directly, the "rot" of the legacy system spreads into the new clean code.
  • The Solution: Implement an Anti-Corruption Layer. This is a translation layer between the two systems.
    • New Service: Speaks its own clean language.
    • ACL: Translates requests from the New Service into the Legacy System's language, and translates responses back.
  • Benefit: The new service remains pure and unpolluted by legacy technical debt.

6. Pros and Cons

Pros Cons
Low Risk: Migration happens in small, manageable steps. Complexity: You have to manage two systems (Legacy + New) simultaneously.
Value Delivery: You can ship new features in the new system immediately. Routing: Requires a robust routing layer (API Gateway/Proxy).
Pause/Resume: You can stop the migration if business priorities change. Data Sync: Keeping data consistent between old and new systems is difficult.

programming/microservices-architecture programming/refactoring-techniques programming/system-design