Step 1: Event Interception (The Proxy)

Stop Talking Directly to the Monolith

To begin strangling the monolith, you first need control over its inputs. You must stop applications and users from talking directly to the legacy system.

You do this by introducing an Intercepting Proxy (also called an API Gateway or Facade) in front of the monolith. Think of it as a receptionist sitting at the front desk of a building. Every visitor (request) must check in with the receptionist before being directed to the right office (service). The receptionist can redirect visitors to a new office without the visitors needing to know the building's internal layout changed.

At first, this proxy does nothing but pass every request straight through to the monolith. It seems pointless — an extra network hop for no benefit. But this "do nothing" phase is critical. It proves the proxy works, establishes baseline latency measurements, and gives you confidence in the routing layer before you start making changes.

Once the proxy is in place, you have a control point. When you build a new microservice to replace a small piece of the monolith (e.g., the "UserProfile" feature), you configure the proxy to divert traffic for /api/userprofile to your new service, while sending everything else to the old system. The users never know the difference.

Here's what this looks like as an NGINX configuration:

# strangler-fig-proxy.conf
upstream legacy_monolith {
    server monolith.internal:8080;
}

upstream new_user_service {
    server user-service.internal:3000;
}

server {
    listen 80;

    # Strangled route — migrated to new service
    location /api/userprofile {
        proxy_pass http://new_user_service;
        proxy_set_header X-Migration-Phase "strangler-fig";
    }

    # Everything else — still goes to the monolith
    location / {
        proxy_pass http://legacy_monolith;
    }
}

In cloud environments, this proxy might be:
- NGINX or HAProxy — for self-managed infrastructure
- AWS API Gateway or ALB path-based routing — for AWS workloads
- Istio or Envoy — for Kubernetes-based service mesh architectures
- Azure Front Door or Application Gateway — for Azure workloads

The choice of proxy technology matters less than the discipline of using one consistently. What matters is that it supports path-based routing, health checks, and weighted traffic splitting (for canary releases later).

Key Point: The proxy introduces a small amount of latency (typically 1-5ms). In rare cases where the legacy system has extremely tight latency requirements (sub-millisecond), you may need to optimize the proxy layer or use a sidecar pattern instead. Always measure baseline latency before and after proxy insertion to quantify the impact. If the proxy adds unacceptable latency, that is a problem to solve now — not after you've routed 50 services through it.