Designing the façade: how API gateways make the strangler fig pattern work

Modernising a legacy system isn’t about replacing everything at once.

It’s about controlling how requests flow while the old and new systems run side by side.

The Strangler Fig pattern gives teams a safe path to do this.

But the real enabler isn’t the new services, it’s the API façade that decides, on every request, whether traffic goes to the monolith or the new module.

This article breaks down how that façade works, why it matters, and the practical patterns that make stepwise modernisation predictable.

Why the façade matters

The Strangler Fig pattern only works when you can do two things reliably:

1. Intercept every request before it hits the legacy system
2. Choose, with precision, whether that request goes to the monolith or the new module

An API gateway gives you both.

Think of it as the single entry point that gradually swaps the old for the new, without forcing an overnight cutover.

The API gateway becomes the operational control centre.

Without it, the migration becomes unpredictable and risky.

The façade’s core responsibilities

These map directly to the pain points we see in legacy modernisation projects across clients:

• Request routing
• Direct traffic to legacy or new services based on path, version, headers, or feature flags.
• Protocol translation
• Legacy uses SOAP? New microservice uses REST or gRPC? The gateway ensures they talk to each other.
• Authentication & authorisation
• Enforce consistent security even while services live in mixed environments.
• Observability
• Centralised logs, metrics, tracing — crucial for “mid-flight” migrations.
• Traffic shaping
• Canary releases, gradual rollout, percentage-based routing.

The gateway doesn’t replace the monolith.

It simply controls the environment around it, and that’s what makes modernisation realistic.

Before and after: how traffic actually changes

Before the façade

All traffic goes directly to the monolith:

Client → Monolith → Database

‍

It’s functional, but rigid. Every change carries system-wide risk.

After introducing an API façade

Traffic now flows through a controlled, observable entry point:

The gateway becomes the single entry point.

Now you can begin peeling away domains safely:

• /auth → new service
• /invoices → migrate gradually
• /orders → keep in monolith temporarily

This is how teams modernise without an overnight switch.

The façade doesn’t just route traffic — it decouples the migration timeline from the release timeline.

Teams can deploy new modules without exposing them to users immediately.

Practical patterns that make the façade work

1. Feature flags for traffic control

Feature flags allow:

• selective routing based on user segments
• instant enabling/disabling of new paths
• reduced blast radius during migration
• gradual rollout without redeploying services

Flags become a non-negotiable tool for rolling out new capabilities safely.

2. Canary routing & progressive rollout

A gateway allows routing by percentage, geography, cohort, or authentication level.

This achieves something a monolith could never do:

validate new services under production load without risking everything.

Example flow:

1. 5% of traffic → new service
2. Monitor latency + error rates
3. If healthy → 20% → 50% → 100%
4. If not → automatic rollback to monolith

Zero downtime. Zero drama.

3. Preventing the façade from becoming a new monolith

A common failure mode: the gateway becomes too smart and absorbs business logic.

To avoid this:

• keep routing rules declarative
• avoid embedding domain logic
• version routing rules alongside services
• keep the gateway thin, replaceable, and infrastructure-focused

The façade should coordinate traffic — not run the business.

What good “mid-flight” architecture looks like

Most modernisation projects live in this temporary state for months or years.

A healthy mid-flight architecture has:

• A stable gateway routing layer
• A predictable set of legacy endpoints still active
• A gradually expanding set of new microservices
• Full transparency into traffic patterns
• A rollback path for every switch you flip

This ensures progress does not compromise reliability — a key principle in our work at Itsavirus.

How engineering teams can start implementing this

A practical sequence we use in real migration projects:

1. Introduce the façade without changing anything

Mirror traffic, add observability, keep all requests flowing to the monolith.

2. Select one low-risk domain

Example: /search, /auth, /notifications.

3. Build the new service behind the gateway

4. Switch routing gradually (feature flags + canary)

Start with low volume, validate, expand.

5. Fully cut off the legacy path once stable

6. Repeat until the monolith becomes thin enough to retire

This iterative rhythm is what makes the Strangler Fig pattern predictable and safe.

Why this works well for regulated and complex environments

Most organisations we work with cannot afford unpredictable migrations.

The façade gives them:

• Stepwise modernisation
• Full auditability
• Controlled rollout
• Minimal disruption to existing workflows
• Ability to pause or reverse anytime

It offers clarity, safety, and operational control — the same principles we emphasise across our AI and modernisation projects. itsavirus_context_profile

The Strangler Fig pattern is not just a conceptual model.

It is an operating model that relies on a robust, disciplined façade to make modernisation feasible.

With the right gateway strategy:

• migrations become measurable
• risks become manageable
• engineering becomes predictable
• and modernisation stops feeling like a rewrite, and starts feeling like controlled evolution

If you're planning to modernise a legacy system, or want to validate whether your gateway strategy is sound, feel free to reach out to our representative here.

We’re always open to share insights or walk through real examples from our work.