Strangler Fig: Bidirectional Sync Failure Lost Finances

Every senior engineer has a war story about the legacy monolith. The codebase that nobody dares touch, where a one-line change takes three weeks of regression testing and still breaks something in production at 2 AM on a Friday. These systems didn't become terrifying overnight — they grew that way over years of feature additions, hotfixes, and 'we'll clean this up later' compromises. The business depends on them. You cannot simply turn them off.

The Strangler Fig Pattern, coined by Martin Fowler in 2004 after observing actual strangler fig trees in Australian rainforests, is an architectural migration strategy that solves one specific problem: how do you replace a working-but-painful system with a better one without a risky, all-or-nothing 'big-bang' rewrite? The answer is that you don't replace it all at once. You intercept traffic at the edge, divert individual capabilities to new services as they're built, and let the old system die by starvation rather than demolition. The risk at any point in time is bounded to the slice you're currently migrating.

By the end of this article you'll understand the full mechanics of the pattern — the proxy/facade layer, feature-by-feature traffic routing, data synchronisation between old and new, rollback strategies, and the production gotchas that turn a smooth migration into a nightmare if you don't see them coming. You'll also have working code for the routing facade and a feature-flag-driven traffic splitter you can adapt to your own stack today.

What Is the Strangler Fig Pattern? (And Why Your Team Needs It)

The Strangler Fig Pattern is a migration strategy that lets you replace a legacy system incrementally, one feature at a time. You put a routing layer — a reverse proxy, API gateway, or even a smart load balancer — in front of the existing monolith. Every incoming request hits this facade instead of the legacy app directly.

The facade checks a routing table (often backed by feature flags) and decides whether to send the request to the old system or the new service. Over time, you build replacement services for each functionality while the legacy app still handles everything else. You route traffic to the new service when it's ready. Once a feature is fully replaced and tested, you remove the legacy code for that feature.

This isn't a new idea — Martin Fowler described it in 2004. But most teams still default to the 'rewrite it all' approach, which collapses under its own risk. The Strangler Fig pattern caps the blast radius of any mistake to exactly one feature.

package io.thecodeforge.proxy;

import java.util.Map;
import java.util.concurrent.ConcurrentHashMap;

public class RoutingFacade {
    private final Map<String, String> routeTable = new ConcurrentHashMap<>();
    private final String legacyBackend;

    public RoutingFacade(String legacyBackend) {
        this.legacyBackend = legacyBackend;
    }

    public void registerMigration(String featurePattern, String newServiceUrl) {
        routeTable.put(featurePattern, newServiceUrl);
    }

    public String resolveBackend(String requestPath) {
        // Check if request path matches any migrated feature
        for (Map.Entry<String, String> entry : routeTable.entrySet()) {
            if (requestPath.startsWith(entry.getKey()) && isActive(entry.getKey())) {
                return entry.getValue();
            }
        }
        return legacyBackend;
    }

    private boolean isActive(String feature) {
        // In production, check a feature flag service (LaunchDarkly, FF4J, etc.)
        return true;
    }
}

Building the Routing Facade: Feature Flags and Traffic Splitting

The facade is the single most critical piece of a Strangler Fig migration. It must be performant, stateless (or externalise state), and observable. Most teams use an API gateway (Kong, Nginx, Envoy) or a reverse proxy with dynamic routing. The key requirement: routing decisions must be changeable at runtime without a deployment.

Feature flags control which users or requests go to the new service. You start at 0% traffic, enable it for internal testing (1% of users), then gradually increase to 100%. The flag can be based on user ID hash, geographic region, or any attribute. If something breaks, you turn the flag off — traffic instantly goes back to legacy.

Don't implement your own feature flag system in-house. Use LaunchDarkly, Unleash, or even a simple Redis-backed toggle. Your only job is to read the flag in the facade, not implement the flag infrastructure.

# TheCodeForge — Strangler Fig routing config for Envoy
# Feature flags are external, loaded from a config service
routing:
  - feature: user-profile
    pattern: "/api/users/**"
    legacy: "monolith.internal"
    new: "user-service.internal"
    # Flag: strangler.user-profile.enabled
    traffic_percent: 30  # will be overridden at runtime via API

  - feature: payments
    pattern: "/api/payments/**"
    legacy: "monolith.internal"
    new: "payment-service.internal"
    traffic_percent: 0  # not yet migrated

  - feature: legacy-fallback
    pattern: "/**"
    backend: "monolith.internal"

Data Synchronisation: The Real Challenge of Strangler Fig

Routing traffic is the easy part. The hard part is keeping data consistent between the legacy database and your new service's database. During migration, both systems need to access and modify the same user data, orders, or inventory. If you don't have a solid data sync strategy, you'll end up with silent corruption.

The safest approach is to have a single source of truth (the legacy database) and have the new service read from it but write to its own database plus the legacy one (dual writes). This keeps both systems in sync. However, dual writes are error-prone — one side can fail while the other succeeds. A better approach is to use change data capture (CDC) from the legacy database: any change in the legacy DB is streamed to a message topic, and the new service consumes that stream to update its own store. The new service's writes are also written to the legacy DB via the same CDC pipeline (reverse sync).

Alternatively, you can migrate data at the database level first (e.g., use database views or federation), but that adds a different kind of coupling. The key is bidirectional replication until you cut over completely.

package io.thecodeforge.migration;

import io.thecodeforge.db.LegacyRepository;
import io.thecodeforge.db.NewServiceRepository;
import org.slf4j.Logger;
import org.slf4j.LoggerFactory;

public class DualWriter {
    private static final Logger log = LoggerFactory.getLogger(DualWriter.class);

    private final LegacyRepository legacy;
    private final NewServiceRepository newService;

    public DualWriter(LegacyRepository legacy, NewServiceRepository newService) {
        this.legacy = legacy;
        this.newService = newService;
    }

    public void writeUserProfile(String userId, UserProfile profile) {
        try {
            legacy.saveProfile(userId, profile);
        } catch (Exception e) {
            log.error("Legacy write failed for user {}, rolling back new write", userId);
            throw e; // Let caller handle rollback
        }
        try {
            newService.saveProfile(userId, profile);
        } catch (Exception e) {
            // New service write failed, but legacy succeeded — need a compensation
            log.warn("New service write failed for user {}, scheduling reconciliation", userId);
            scheduleReconciliation(userId, profile);
        }
    }

    private void scheduleReconciliation(String userId, UserProfile profile) {
        // Push to dead-letter queue for later retry
    }
}

Rollback Strategy: How to Undo a Migration Without Pain

A good strangler fig migration must have a rapid rollback plan for every slice. The beauty of the pattern is that the legacy system never goes away until the last feature is migrated. You can always flip the routing flag back to legacy for a particular feature.

But a simple routing rollback isn't always enough — you also need to handle data. If the new service wrote data that doesn't exist in legacy, you can lose it on rollback. The rule: the legacy system must be the authoritative writer until cutover. Any writes from the new service must be replicated back to legacy (dual writes or CDC reverse sync). That way, when you flip the routing back, the legacy system has all the data.

Your rollback sequence: 1) Turn off the feature flag (stop routing traffic to new service). 2) Verify the legacy system can serve all the data (run a data consistency check). 3) If data is missing, run a backfill from the new service's database. 4) Decommission new service only after at least 48 hours of clean rollback window.

Test your rollback before you need it. Simulate a failure scenario in staging: let the new service crash and verify that the routing facade correctly falls back to legacy without any UX interruption.

#!/bin/bash
# TheCodeForge — Strangler Fig rollback script
# Usage: ./rollback.sh <feature-name>

FEATURE=$1
FLAG_SERVICE="https://flags.internal/flag"

# Step 1: Disable the feature flag
curl -X POST "$FLAG_SERVICE/strangler.$FEATURE.enabled" \
  -H "Content-Type: application/json" \
  -d '{"enabled": false}'

# Step 2: Wait for proxy to pick up the change
sleep 5  # depends on your proxy cache TTL

# Step 3: Verify traffic is going to legacy
curl -I "http://proxy/api/$FEATURE/health" 2>&1 | grep -q "X-Backend: legacy"
if [ $? -eq 0 ]; then
  echo "Rollback successful: traffic now to legacy"
else
  echo "ERROR: Traffic still hitting new service"
  exit 1
fi

# Step 4: Check data consistency
# (assuming a reconciliation job runs offline)
echo "Rollback complete. Monitor reconciliation status."

When NOT to Use the Strangler Fig Pattern

The Strangler Fig pattern isn't a silver bullet. It works best for replacing parts of a monolithic system where you can isolate a single capability. It fails when:

• The legacy system has no clear interface boundaries — everything is tightly coupled through a shared database or global state. In that case, you can't extract a single feature without dragging half the monolith with it.
• The new system requires a fundamentally different data model that can't be mapped to the legacy one. If every request needs to transform heavily between old and new schema, the proxy becomes a bottleneck.
• You need performance improvements immediately — the strangler fig approach adds latency from the proxy and dual writes for many months. If you need to make the system 2x faster this quarter, a rewrite (with careful planning) might be the better call.
• The team is unwilling to maintain two codebases in parallel. The pattern requires you to keep the legacy app around until migration is complete. If your team can't handle that cognitive load, consider a big-bang migration with a well-tested rollback plan instead.

Evaluate your specific context. The pattern is a tool, not a religion.