Strangler Fig Edge Routing & Session Affinity

Stack: SOFTWARE ARCHITECTURE STACK →Senior (L5)pattern

⚡THE SHORT ANSWER

The Strangler Fig pattern incrementally replaces legacy monolithic features with modern microservices by intercepting incoming traffic at an edge reverse proxy, requiring robust session synchronization and authentication bridging to ensure seamless user experiences.

Engineering Handbook & Failure Dynamics

6-Dimensional Architecture Breakdown

⚙️1. Underlying Mechanism

Execution

Named after strangler fig trees that slowly grow around a host tree until they replace it entirely, this pattern avoids high-risk 'Big Bang' rewrites. An edge API gateway (Envoy, NGINX, Cloudflare) intercepts incoming HTTP requests. Routes for migrated capabilities (e.g. /api/v1/auth, /api/v1/billing) route to new microservices, while all un-migrated paths default to the legacy monolith.

🎯2. Appropriate Use Context

Scope

The Strangler Fig pattern is an architectural migration strategy where a legacy application is gradually replaced by building new features or migrating existing ones into independent services, routing traffic at the network edge without disturbing unchanged systems.

⚠️3. Production Failure Modes

P0 Risk

Attempting a 'Big Bang' multi-year rewrite where all legacy code is replaced in a single massive weekend deployment. Rewriting backend business logic while simultaneously changing database schemas and redesigning the frontend UI. Allowing the new microservice to call internal private methods inside the monolith codebase directly.

📡4. Diagnostic Signals & Telemetry

Telemetry

user session lost when navigating between monolith and new microservice, cookie domain mismatch logging user out during strangler migration, reverse proxy routing loop between legacy and new service

🛡️5. Prevention & Safeguards

Safeguards

Place the reverse proxy / API Gateway in front of the monolith on Day 1 of the migration. Use Shadow Traffic (traffic mirroring) to validate the new service's latency and error rate under real production traffic loads. Migrate non-critical, high-value read-only endpoints first to build organizational confidence before migrating complex write paths.

⚖️6. Architectural Trade-offs

Trade-off

Big-bang rewrites have an 80%+ historical failure rate; Strangler Fig allows continuous delivery of business value during multi-year migrations while maintaining instantaneous rollback safety.

📋

Case Study (TinyCTO In-Field Example)

REAL-WORLD TELEMETRY

The greatest technical obstacle during a Strangler Fig migration is Authentication & Session Bridging:

▸
The Shared Session Problem: Monoliths typically store sessions in local memory or relational DB tables (e.g. express-session, PHP sessions). When a user navigates to /billing (hosted on a new Go microservice), the new service cannot validate the legacy opaque session cookie.
▸
The JWT / Token Translation Gateway: The reverse proxy intercepts requests, extracts the legacy session cookie, resolves the user identity via a fast Redis cache, and injects a signed Authorization: Bearer <JWT> header before forwarding to the microservice.
▸
Shadow Traffic / Dark Launching: Before flipping the route live, the reverse proxy duplicates incoming live production GET requests to the new service asynchronously to verify performance and response parity without impacting users.

Interactive Concept Drills

2 Cards

What is the core principle of the Strangler Fig migration pattern?

Gradually replacing monolith features with new microservices behind an edge reverse proxy until the monolith can be safely decommissioned.

How does Shadow Traffic (Traffic Mirroring) derisk a Strangler Fig migration?

It clones live production HTTP requests to the new service asynchronously, allowing engineers to verify performance and correctness without impacting real users.