# Strangler fig pattern > The strangler fig pattern replaces an existing system a piece at a time while the old and new implementations run side by side. It reduces the risk of a big-bang rewrite, but requires clear routing, data ownership, and retirement plans so the temporary architecture does not become permanent. Source: https://sysround.com/concepts/strangler-fig Updated: 2026-11-05 ## How strangler fig pattern works Put a routing boundary in front of the functionality you want to replace. An API gateway, reverse proxy, or internal interface sends requests either to the legacy implementation or its replacement while keeping the client-facing contract stable. Choose a bounded capability to extract, such as notification preferences from a larger account application. Route that capability to the new implementation while login, billing, and other behavior stay in the legacy system; the replacement does not have to be a microservice. Preserve behavior at the boundary. An adapter can translate old request formats, identifiers, and error responses into the new model, preventing legacy assumptions from spreading throughout the replacement. Plan data ownership separately from request routing. Initially, the new code might access the existing database; later, a snapshot and change data capture can populate a separate store. Before switching writes, define one authoritative writer for each migrated capability or entity and fence the old write path. Move traffic in controlled stages, validate correctness and latency, and retire each replaced path. Shadow reads can compare results without changing responses, but shadow writes must not trigger real side effects. Once all callers and dependencies have moved, remove the legacy code, obsolete data access, and temporary adapters. ## Worked example: Extracting notification preferences from an account application An account application handles 2,000 requests per second, including 200 preference reads and 20 preference updates. First, put its existing API behind a router and build a replacement preferences service. Backfill its database, then apply captured changes while the legacy application remains the only writer. Compare shadow reads without exposing their results. For cutover, briefly pause preference updates, drain in-flight writes, and verify that replication has caught up. Fence legacy preference writes, then route all preference reads and updates to the new service. Login and billing remain unchanged. Keep the old handler disabled; do not promise instant rollback unless it can safely read and write the new authoritative state. ## Trade-offs - **Smaller cutovers, longer coexistence.** Each migration affects less functionality, but operating two implementations increases infrastructure, testing, and on-call work. - **Stable clients, more routing complexity.** A facade hides migration from clients but introduces routing rules and another component whose failure behavior must be designed. - **Incremental extraction, difficult transaction boundaries.** Splitting tightly coupled capabilities can turn a local transaction into a cross-system workflow, so extraction boundaries should preserve important invariants. - **Independent storage, synchronization costs.** Separate databases enable independent evolution but require backfills, change propagation, reconciliation, and explicit ownership transfer. - **Traffic rollback is not data rollback.** After the new system accepts writes, routing requests back is safe only if the old implementation can access and interpret the current authoritative state. - **Gradual progress, risk of an unfinished migration.** Without retirement milestones and dependency tracking, temporary adapters and legacy infrastructure can remain indefinitely. ## When to use it in a system design interview - The prompt explicitly asks you to modernize or replace an existing production system without a long outage. - A full rewrite would require switching too many clients, workflows, or datasets at once. - The existing system has capabilities that can be isolated behind stable interfaces and migrated independently. - You need to preserve existing API behavior while changing the implementation, technology stack, or service boundaries. ## How to bring it up in the interview - Start with the migration constraint rather than the pattern name: explain why an incremental replacement is safer than a single cutover, and identify the first bounded capability to move. - Draw the routing boundary and mark the authoritative writer for every phase; interviewers will probe bypass paths, background jobs, and transactions that cross the boundary. - Separate code rollout, traffic rollout, and data cutover; explain what you can reverse at each stage and what happens to writes already accepted by the replacement. - Define validation and completion criteria: compare outputs, monitor errors and latency, reconcile data, inventory remaining callers, and state when the legacy path can be deleted. ## Common mistakes - Calling any gradual deployment a strangler migration; canary deployment changes traffic exposure, while the strangler pattern progressively replaces responsibilities. - Routing by individual request when a stateful workflow needs stable ownership across all its requests. - Treating independent writes to old and new databases as reliable synchronization without handling partial failures and conflicts. - Assuming a proxy switch guarantees rollback after the new system has changed data or introduced incompatible behavior. - Extracting services without identifying shared tables, scheduled jobs, and internal callers that still depend on legacy behavior. ## FAQ ### What is the strangler fig pattern? It is an incremental replacement strategy in which new functionality takes over responsibilities from an existing system behind a stable boundary. The old system continues serving everything not yet migrated and is retired when its remaining responsibilities disappear. ### How is the strangler fig pattern different from a big-bang rewrite? A big-bang rewrite replaces the system in one major cutover, concentrating compatibility and migration risk at that moment. The strangler pattern spreads that risk across smaller migrations, at the cost of operating old and new implementations together. ### Does the strangler fig pattern require microservices? No. The replacement can be another monolith, a module, or several services. The defining feature is incremental transfer of responsibilities, not the number of deployment units. ## Related concepts - [Reverse proxy](https://sysround.com/concepts/reverse-proxy) - [Change data capture](https://sysround.com/concepts/change-data-capture) - [Zero-downtime migrations](https://sysround.com/concepts/zero-downtime-migrations) - [Canary deployment](https://sysround.com/concepts/canary-deployment) --- SysRound (https://sysround.com) is an AI practice tool for system design interviews: a voice or typed AI interviewer, a shared whiteboard, then feedback on every skill and a model answer. Its feedback is AI-generated and can be wrong.