Strangler Fig Migration: From Monolith to Microservices Gradually

The $100 Million Rewrite That Failed

Netscape tried a big-bang rewrite of their browser in 1998. It took three years, and the company nearly died. The same pattern plays out in backend systems: 'Let us rewrite the monolith from scratch in microservices.' Two years later, the new system covers 60% of features, the old system has added 40% more features, and both are half-broken.

The Strangler Fig Approach

Named after the strangler fig tree that grows around an existing tree, eventually replacing it. You build new services alongside the monolith, gradually routing traffic to them until the monolith has nothing left to do.

Strangler Fig Migration - Timeline:

  Phase 1: Intercept                Phase 2: Extract
  +-----------+                     +-----------+
  |  Routing  |                     |  Routing  |
  |   Layer   |                     |   Layer   |
  +-----+-----+                     +--+-----+--+
        |                              |     |
        v                              v     v
  +----------+                   +------+ +----------+
  | Monolith |                   | Auth | | Monolith |
  | (all)    |                   | Svc  | | (rest)   |
  +----------+                   +------+ +----------+

  Phase 3: Grow                     Phase 4: Complete
  +-----------+                     +-----------+
  |  Routing  |                     |  Routing  |
  |   Layer   |                     |   Layer   |
  +--+--+--+--+                     +--+--+--+--+
     |  |  |                           |  |  |
     v  v  v                           v  v  v
  +--+ +--+ +------+              +--+ +--+ +------+
  |Au| |Or| | Mono |              |Au| |Or| |Prod  |
  |th| |dr| | (shrinking)         |th| |dr| |Svc   |
  +--+ +--+ +------+              +--+ +--+ +------+

  The monolith SHRINKS as services GROW around it.

Step-by-Step Extraction

1. Place a routing layer (API gateway or reverse proxy) in front of the monolith - all traffic flows through it
2. Pick ONE bounded context to extract (start with the simplest, lowest-risk one)
3. Build the new service alongside the monolith - both run simultaneously
4. Route traffic for that context from the monolith to the new service
5. Run both in parallel and compare results (dual-write or shadow mode)
6. Once confident, cut over fully and delete that code from the monolith
7. Repeat for the next bounded context

Choosing What to Extract First

Extraction Priority Matrix:

Candidate       Coupling  Change Freq  Data Isolation  Risk   Score
--------------  --------  -----------  --------------  -----  -----
Auth/Login      Low       Low          Own tables      Low    GOOD
Notifications   Low       Medium       Own tables      Low    BEST
Product Search  Medium    High         ES + own tables Medium GOOD
Order System    HIGH      High         Joins 12 tables High   AVOID
Payments        Medium    Low          Own tables      High   WAIT

  Best first extraction:
  - LOW coupling (few calls to/from other monolith code)
  - Clear data ownership (its own tables, few cross-joins)
  - LOW risk (not revenue-critical)
  - HIGH team pain (changes frequently, blocks other teams)

  Worst first extraction:
  - High coupling (tangled with everything)
  - Shared data (joined with 15 other tables)
  - Revenue-critical (if it breaks, money stops)

The Shared Database Problem

The hardest part of any extraction is data. The monolith's Order table joins with User, Product, Inventory, and Payment tables. You cannot just rip it out. Real companies solve this in stages.

Database Extraction Strategy:

  Step 1: Logical separation (same DB, separate schemas)
  +------------------+
  | PostgreSQL       |
  |  [monolith.*]    |  <-- monolith reads/writes
  |  [orders.*]      |  <-- new service reads/writes
  +------------------+

  Step 2: Data sync via CDC (Change Data Capture)
  [Orders DB] --CDC--> [Event Stream] ---> [Monolith DB]
  New service is source of truth for orders.
  Monolith gets read-only copies via events.

  Step 3: API calls replace direct DB access
  Monolith calls GET /api/orders/user/123
  instead of SELECT * FROM orders WHERE user_id=123

  Step 4: Remove order tables from monolith DB entirely

Who Has Done This

Company     Duration   From                 To
----------  ---------  -------------------  --------------------
Amazon      ~6 years   Perl/C monolith      SOA then microsvcs
Netflix     ~7 years   Data center monolith Cloud microservices
Shopify     Ongoing    Modular monolith     Selective extraction
SoundCloud  ~3 years   Rails monolith       Scala microservices
Etsy        ~4 years   PHP monolith         Still extracting

  Note: These migrations take YEARS at large companies.
  Amazon started around 2001, considered it 'done' in ~2007.

Interview Tip

If an interviewer asks how you would break up a monolith, say: 'I would use the strangler fig pattern. First, I place a routing layer in front. Then I identify bounded contexts with low coupling and clear data ownership - like notifications or authentication. I extract those first into independent services with their own databases, using CDC to keep data synchronized during the transition. I would never do a big-bang rewrite. The key is incremental extraction over months, where the monolith shrinks naturally as services grow around it.'

Key Takeaway

The strangler fig pattern migrates monolith to microservices incrementally. Route traffic through a proxy, extract one bounded context at a time, verify it works, delete from the monolith. No big bang, no downtime, no massive risk. The key is patience - it takes months or years for large systems.