Stackbook Logo
migration

Strangler Pattern

Intent

gradually replace a legacy system by adding new functionality through new services rather than modifying the existing monolith, allowing the old system to slowly 'strangle' as new capabilities take over.

Problem

Monolithic legacy systems become increasingly difficult to maintain, scale, and extend. Full rewrites are risky, expensive, and often fail. Organizations need a path to modernize incrementally.

Forces

    Solution

    Strangler Pattern

    A migration strategy for gradually replacing a legacy monolithic system by incrementally extracting bounded contexts into new services.

    The Core Idea

    Instead of a risky big-bang rewrite, you "strangle" the old system. New functionality is added through new services, and over time the monolith becomes irrelevant — its functionality lives in modern, independently deployable services.

    How It Works

    1. Identify a bounded context — Find a cohesive domain in the monolith that can be extracted (e.g., "order management", "billing", "user profiles")

    2. Build a new service — Implement that functionality as an independent service with its own database and API

    3. Route traffic — Use an API gateway, route handlers, or feature flags to direct requests for that domain to the new service instead of the monolith

    4. Decommission the module — Once the new service is stable, remove the corresponding code from the monolith

    5. Repeat — Continue until the monolith is fully decomposed

    Key Tactics

    • API Gateway routing: Configure the gateway to map URLs to new services
    • Feature flags: Gradually shift percentage of users to the new service
    • Strangler Fig wrapper: A thin layer around the monolith that delegates to new services for known capabilities
    • Database per service: Each extracted service owns its data (eventual consistency during transition)

    When to Use

    • Migrating from monolith to microservices
    • Needing to deliver new features while migrating incrementally
    • Monolith is too large to fully understand, but specific domains are clear
    • Requiring zero-downtime migration

    When Not to Use

    • Tight coupling across all monolith domains (extraction impossible)
    • Performance requires direct in-process calls (microservice overhead)
    • Team lacks distributed systems operational expertise

    Cost Profile

    | Category | Assessment | |----------|-----------| | Infrastructure | Medium — API gateway, service infra | | Operational | Medium — dual operation during transition | | Cognitive | High — complex routing & cutover logic |

    Real-World Examples

    • Netflix API migration: Graduated migration from monolith to microservices
    • ThoughtWorks delivery pipeline: Strangler pattern for enterprise systems

    Alternatives

    ✓ When to Use

    • •When migrating from a monolith to microservices
    • •When you need to deliver new features but cannot rewrite the entire system
    • •When the monolith is too large to understand fully but specific domains can be extracted
    • •When you want zero-downtime migration

    ✗ When Not to Use

    • •When the monolith has tight coupling across all domains (extraction impossible)
    • •When performance requirements demand direct in-process calls (microservice overhead)
    • •When the team lacks operational expertise for distributed systems

    Pros

    • +Incremental: No big-bang rewrite risk
    • +Low risk: Each step is small and reversible
    • +Continuous delivery: New features shipped while migrating
    • +Domain-driven: Natural boundaries emerge from business capabilities

    Cons

    • −Routing complexity: Needs API gateway or routing layer
    • −Dual-run overhead: Both monolith and services exist simultaneously
    • −Data consistency: Need to handle duplicate/consistent state during transition
    • −Organizational: Requires team to split focus between old and new

    Cost Profile

    Infrastructure

    Operational

    Cognitive

    Failure Modes

      Real-World Examples

      Alternatives

        Related Patterns

          Competency Domains

          distribution communicationreliability ops