What You Will Learn

• What is Strangler Fig Pattern?
• Why Legacy Modernization is Difficult
• Monolith Migration Challenges
• Incremental Migration Strategy
• API Gateway Routing
• Strangler Architecture
• Migration Phases
• Banking Modernization Examples
• Enterprise Use Cases
• Benefits and Limitations
• Interview Questions

---

Introduction

Many enterprise systems are:

10+ Years Old

Large Monoliths

Millions Of Lines Of Code

Critical Business Systems

Examples:

Banking Platforms

Insurance Systems

Retail Platforms

Healthcare Applications

Question:

How do we migrate

without shutting down production?

Rewriting everything at once is risky.

Strangler Fig Pattern solves this problem.

---

What is Strangler Fig Pattern?

Strangler Fig Pattern is a gradual migration strategy that replaces parts of a legacy monolith with new services over time.

Instead of:

Big Bang Rewrite

Use:

Incremental Replacement

---

Why The Name?

Inspired by:

Strangler Fig Tree

The tree grows around another tree.

Eventually:

Old Tree Removed

New Tree Remains

Same concept for software.

---

Purpose of Strangler Fig Pattern

Primary Goal:

Modernize Legacy Systems

Without Business Disruption

---

Traditional Migration Approach

Rewrite Everything

Problems:

High Risk

Long Timelines

Expensive

Frequent Failures

---

Big Bang Migration

flowchart LR

A[Legacy Monolith]

B[Rewrite Entire System]

C[Go Live]

A --> B
B --> C

Very risky.

---

Strangler Approach

flowchart LR

A[Legacy Monolith]

B[New Services]

A --> B

Migrate gradually.

---

Initial State

flowchart LR

A[Client]

B[Monolith]

A --> B

Everything runs inside monolith.

---

Migration Goal

flowchart LR

A[Client]

B[Microservices]

A --> B

Monolith removed.

---

Incremental Migration

Instead of:

Replace Entire System

Replace:

One Feature At A Time

---

Example Banking Monolith

Accounts

Transfers

Loans

Cards

Notifications

Statements

All inside one application.

---

Banking Monolith Architecture

flowchart LR

A[Customer]

B[Banking Monolith]

A --> B

---

First Migration Step

Extract:

Notification Service

from monolith.

---

Phase 1 Architecture

flowchart LR

A[Client]

B[Monolith]

C[Notification Service]

A --> B
B --> C

---

Next Migration

Extract:

Loan Service

---

Phase 2 Architecture

flowchart LR

A[Client]

B[Monolith]

C[Notification Service]

D[Loan Service]

A --> B

B --> C
B --> D

---

Final Migration

All modules extracted.

---

Final Architecture

flowchart LR

A[Client]

B[Account Service]

C[Loan Service]

D[Card Service]

E[Notification Service]

A --> B
A --> C
A --> D
A --> E

Monolith retired.

---

Core Components

Legacy System

API Gateway

New Services

Routing Rules

---

Strangler Architecture

flowchart LR

A[Client]

B[API Gateway]

C[Legacy Monolith]

D[New Services]

A --> B

B --> C
B --> D

Gateway decides routing.

---

API Gateway Role

Gateway routes requests:

Old Features

→ Monolith

New Features

→ Microservices

---

Routing Example

flowchart LR

A[Client]

B[API Gateway]

C[Monolith]

D[Customer Service]

A --> B

B --> C
B --> D

---

Migration Workflow

Step 1:

Identify Module

---

Step 2

Build New Service

---

Step 3

Deploy Service

---

Step 4

Route Traffic

---

Step 5

Retire Old Module

---

Migration Lifecycle

flowchart LR

A[Monolith Module]

B[Build Service]

C[Deploy]

D[Route Traffic]

E[Remove Legacy Module]

A --> B
B --> C
C --> D
D --> E

---

Example: User Management

Legacy Endpoint:

/users

Inside monolith.

---

After Migration

Gateway routes:

/users

↓

User Service

instead of monolith.

---

User Service Migration

flowchart LR

A[API Gateway]

B[User Service]

C[Monolith]

A --> B
A --> C

---

Banking Example

Modules:

Accounts

Loans

Cards

Payments

Notifications

Migration Order:

Notifications

Cards

Loans

Payments

Accounts

---

Banking Architecture

flowchart LR

A[Client]

B[API Gateway]

C[Legacy Core Banking]

D[Loan Service]

E[Card Service]

F[Notification Service]

A --> B

B --> C
B --> D
B --> E
B --> F

---

Insurance Example

Legacy Platform:

Claims

Policies

Premiums

Payments

---

Migration Strategy

Extract:

Claims Service

Policy Service

first.

---

Insurance Architecture

flowchart LR

A[Portal]

B[Gateway]

C[Legacy System]

D[Claim Service]

E[Policy Service]

A --> B

B --> C
B --> D
B --> E

---

E-Commerce Example

Legacy Modules:

Catalog

Orders

Inventory

Payments

---

Migration Flow

flowchart LR

A[Legacy Store]

B[Catalog Service]

C[Order Service]

D[Inventory Service]

A --> B
A --> C
A --> D

---

Data Migration Challenge

Applications often share:

Single Database

---

Initial Database

flowchart LR

A[Monolith]

B[Shared Database]

A --> B

---

Target Database Architecture

flowchart LR

A[Account Service]

B[Account DB]

C[Loan Service]

D[Loan DB]

A --> B
C --> D

Each service owns data.

---

Strangler + Event Driven Architecture

Common combination.

---

Event Driven Migration

flowchart LR

A[Monolith]

B[Kafka]

C[New Service]

A --> B
B --> C

Events synchronize systems.

---

Benefits Of Strangler Pattern

Low Risk

Gradual Migration

---

Faster Delivery

Feature By Feature

---

Reduced Downtime

No Big Bang Release

---

Business Continuity

Production Continues Running

---

Technology Modernization

Java 21

Spring Boot

Kubernetes

Cloud Native

---

Challenges

❌ Duplicate Logic

❌ Temporary Complexity

❌ Routing Complexity

❌ Data Synchronization

❌ Long Migration Timelines

---

Strangler vs Big Bang Migration

Feature	Strangler	Big Bang
Risk	Low	High
Downtime	Minimal	High
Delivery Speed	Incremental	Delayed
Complexity	Medium	High
Failure Impact	Small	Large

---

Strangler vs Rewrite

Feature	Strangler	Rewrite
Existing System Running	Yes	No
Incremental	Yes	No
Safer	Yes	No
Preferred Enterprise Approach	Yes	Rarely

---

Enterprise Use Cases

Banking

Core Banking Modernization

Loan Systems

Card Platforms

---

Insurance

Claim Systems

Policy Platforms

---

Retail

Order Systems

Inventory Platforms

---

Healthcare

Patient Management

Billing Systems

---

Government

Citizen Services

Tax Systems

---

Real Enterprise Architecture

flowchart LR

A[Mobile App]

B[Web Portal]

C[API Gateway]

D[Legacy Monolith]

E[User Service]

F[Order Service]

G[Payment Service]

H[Notification Service]

A --> C
B --> C

C --> D
C --> E
C --> F
C --> G
C --> H

---

Migration Roadmap

Phase 1
Notification Service

Phase 2
User Service

Phase 3
Order Service

Phase 4
Payment Service

Phase 5
Retire Monolith

---

When To Use Strangler Pattern

Use when:

Large Legacy Systems

Monolith To Microservices

Cloud Migration

Digital Transformation

---

When NOT To Use

Avoid when:

Small Applications

Recently Built Systems

Simple Refactoring

---

Interview Questions

What is Strangler Fig Pattern?

A gradual migration strategy that replaces a legacy system piece by piece.

---

Why Use It?

To modernize systems with lower risk.

---

Why Called Strangler Fig?

Inspired by the Strangler Fig tree that gradually replaces another tree.

---

Main Benefit?

Incremental modernization without downtime.

---

Gateway Role?

Routes requests between monolith and new services.

---

Commonly Used With?

API Gateway

Kafka

Microservices

Event Driven Architecture

---

Biggest Challenge?

Data migration and temporary complexity.

---

Key Takeaways

• Strangler Fig Pattern enables gradual migration from monoliths to microservices.
• Avoids risky big-bang rewrites.
• Uses API Gateway for traffic routing.
• Commonly combined with Kafka and Event Driven Architecture.
• Widely used in Banking, Insurance, Retail, Healthcare, and Government modernization projects.
• One of the most important enterprise modernization patterns.
• Preferred migration strategy for large legacy systems.

---