Strangler Fig for APIs

Overview

Named after the fig that grows around a host tree, the strangler fig pattern grows a new API around an old one until the old one can be removed. Applied to APIs, the routing layer decides per endpoint which implementation answers.

How it works

A facade sits in front of both systems. Initially every route goes to legacy. Each migrated endpoint flips a rule.

client -> facade
  /v1/orders/*    -> new-orders-service   (migrated)
  /v1/invoices/*  -> legacy-api           (not yet)
  /v1/customers/* -> 10% new, 90% legacy  (canary)

A typical sequence: pick a low-risk, well-bounded endpoint; build it in the new system; run both and diff responses in shadow mode; route a small percentage; raise to 100 percent; remove the legacy code. Data ownership must be settled per slice, using either synchronisation, change data capture, or having the new service become the system of record.

Pitfalls

• Migrating by technical layer instead of business capability, which leaves no usable slice.
• Both systems writing the same tables. Decide a single writer per entity.
• Forgetting the finish. Track remaining routes and set a decommission date.
• Undocumented legacy behaviour. Shadow comparison reveals quirks clients rely on.
• Treating the facade as free; it needs redundancy and monitoring.

Key takeaways

• Route per endpoint, migrate in small reversible steps.
• Verify with shadow traffic and canaries before cutover.
• Settle data ownership for every slice.
• Plan and measure the removal of the legacy system.
• Measure it in production: track latency, error rates and volume for this pattern, and review the numbers regularly so that limits and timeouts stay matched to real traffic.