Strangler Fig Pattern in System Design

An old application still serves customers, but one part needs a new implementation. Replacing everything at once can make it difficult to compare behaviour, recover from mistakes and keep the service running.

The strangler fig pattern gradually routes selected responsibilities to a replacement while the legacy system continues serving the rest. A facade or router can control that boundary. It is a migration strategy, not a promise that every old application can be split easily.

Start from a capability and its dependencies. A public catalogue read may be easier to isolate than a payment operation touching several shared tables. Identify callers, data writes, scheduled jobs and external effects before moving traffic.

The new implementation needs an agreed contract. Preserve important request and response behaviour, permissions and error semantics, or deliberately version the interface for callers.

Small increments make observation and recovery easier, but an increment must still be coherent. Moving an endpoint without its data rules can leave two implementations disagreeing about ownership.

A new catalogue service is ready for limited read traffic. Later, the team wants to move stock updates. Select a plan for each transition.

The exercise records a proposed decision. Real migration requires representative tests, data checks and a concrete rollback procedure.

Moving reads and moving writes have different risks. A read copy needs a freshness and validation rule. A new authoritative writer needs a plan for old callers, background jobs and recovery.

Dual writes can fail between destinations. Change-data capture, an outbox, or a product-supported migration mechanism may help particular flows, but each needs ordering, duplicates and reconciliation rules.

Compatibility can require additive schema changes and a staged rollout. If the replacement writes data the legacy code cannot understand, flipping traffic back is not a complete rollback.

Define cutover checks: representative successful responses, authorization, failure outcomes, latency, data agreement and external effects. A shadow read can compare responses, but do not blindly shadow writes that charge, email or create duplicate actions.

Monitor route ownership and remaining legacy callers. Remove old code only after dependencies and background work are accounted for. The migration facade itself needs capacity, availability and understandable configuration.

AWS strangler fig guidance describes gradual replacement through a routing boundary. Source checked 6 October 2026. The pattern adds a transition period where both implementations must be operated.

Compare the Anti-Corruption Layer for business-model translation and Adapter for a narrower interface mismatch. Facade can give callers a stable subsystem operation while responsibilities move.

Gradual replacement can reduce cutover risk when slices have clear contracts. Track ownership, dependencies and evidence for each step.

Plan data migration and rollback alongside routing. Finish by verifying remaining callers and retiring the old path deliberately.