When organizations scale, a simple monolithic architecture often becomes difficult to maintain, deploy, and scale. This is where microservices come into the picture.
However, moving to microservices introduces new challenges:
- How do we migrate from a monolith safely?
- How do we handle transactions across multiple services?
- How do we scale read-heavy applications efficiently?
Three popular patterns solve these problems:
Strangler Pattern – Monolith to Microservices Migration
Saga Pattern – Distributed Transaction Management
CQRS (Command Query Responsibility Segregation) – Read/Write Scalability
1. Strangler Pattern
Why Do We Need It?
Most companies cannot shut down a production monolith and rewrite everything from scratch.
A complete rewrite is risky because:
- Development takes a long time.
- Existing customers are affected.
- Bugs can impact business operations.
- Rollback becomes difficult.
The Strangler Pattern allows teams to migrate gradually with minimal risk.
What Is It?
The Strangler Pattern is a migration strategy where new microservices slowly replace parts of a monolithic application until the monolith is no longer needed.
The name comes from the strangler fig tree, which gradually grows around another tree and eventually replaces it.
How Does It Work?
[Insert diagram here showing Client → API Gateway → Monolith + Microservices]
Step 1
All requests go to the monolith.
Client
|
v
Monolith
Step 2
Introduce an API Gateway (or Controller).
Client
|
v
API Gateway
|
v
Monolith
Step 3
Extract one module into a microservice.
Client
|
v
API Gateway
|------> Order Service
|
v
Monolith
Step 4
Gradually move more modules.
Client
|
v
API Gateway
|------> Order Service
|------> Payment Service
|------> Inventory Service
|
v
Monolith
Step 5
Eventually remove the monolith completely.
Example
Consider an e-commerce application.
Initially, everything exists inside one application:
Monolith
├── Orders
├── Payments
├── Inventory
└── Users
Over time:
- Orders become Order Service
- Payments become Payment Service
- Inventory becomes Inventory Service
The gateway routes requests to the correct service while reducing dependency on the monolith.
Advantages
- Low-risk migration
- No system downtime
- Incremental development
- Easy rollback
Disadvantages
- Additional routing complexity
- Temporary duplicate logic
- Gateway becomes a critical component
Interview One-Liner
Strangler Pattern gradually replaces a monolithic application with microservices by routing traffic through a gateway and migrating features incrementally.
Database Per Service vs Shared Database
Before understanding Saga, it is important to understand how data is managed in microservices.
Shared Database
Architecture
Order Service
Payment Service
Inventory Service
|
v
Shared DB
Why Use It?
Because it provides:
- Easy JOIN operations
- ACID transactions
- Simpler initial development
Problems
- Tight coupling between services
- Difficult independent scaling
- Schema changes affect multiple services
Database Per Service
Architecture
Order Service -----> Order DB
Payment Service ---> Payment DB
Inventory Service -> Inventory DB
Why Is It Preferred?
Each service owns its own data.
Benefits:
- Independent scaling
- Better fault isolation
- Service autonomy
- Technology flexibility
Interview One-Liner
Database-per-service is preferred because it enables loose coupling, independent scaling, and service ownership.
2. Saga Pattern
Why Do We Need It?
In a monolith, a transaction is simple.
BEGIN;
Debit Account A;
Credit Account B;
COMMIT;
Everything succeeds or everything rolls back.
In microservices, data is distributed across multiple databases.
A single transaction may involve:
- Order Service
- Inventory Service
- Payment Service
Traditional ACID transactions no longer work across multiple databases efficiently.
This creates the Distributed Transaction Problem.
What Is It?
The Saga Pattern is a sequence of local transactions that work together to complete a business process.
If one step fails, compensating actions undo previously completed steps.
How Does It Work?
[Insert diagram here showing Order → Inventory → Payment → Confirmation]
Successful Flow
Create Order
|
v
Reserve Inventory
|
v
Process Payment
|
v
Confirm Order
Failure Flow
Create Order
|
v
Reserve Inventory
|
v
Payment Failed
|
v
Release Inventory
|
v
Cancel Order
Instead of rolling back a database transaction, Saga performs business-level rollback.
Example
Order Placement System
Step 1
Order Service creates an order.
Step 2
Inventory Service reserves stock.
Step 3
Payment Service charges the customer.
Step 4
Order gets confirmed.
Now imagine payment fails.
The Saga triggers compensation:
Payment Failed
|
v
Release Reserved Inventory
|
v
Cancel Order
The system remains consistent.
Types of Saga
1. Choreography
Services communicate through events.
Order Service
|
v
Inventory Service
|
v
Payment Service
Each service listens and reacts to events.
Pros
- Loosely coupled
- No central controller
Cons
- Difficult to debug
- Event chains become complex
2. Orchestration
A central orchestrator controls the workflow.
Orchestrator
|
-------------------
| | |
Order Inventory Payment
Pros
- Easier monitoring
- Clear workflow
Cons
- Central coordinator dependency
Advantages
- Solves distributed transaction problems
- Maintains consistency
- Handles failures gracefully
Disadvantages
- More complex than local transactions
- Requires compensation logic
- Harder debugging
Interview One-Liner
Saga Pattern maintains consistency across multiple microservices using local transactions and compensating actions instead of distributed ACID transactions.
3. CQRS (Command Query Responsibility Segregation)
Why Do We Need It?
Most applications are read-heavy.
Example:
- Social Media Feed
- E-Commerce Product Search
- Analytics Dashboard
Typical traffic:
Reads = 95%
Writes = 5%
Using the same model for both reads and writes can become a bottleneck.
What Is It?
CQRS separates:
- Commands (Write Operations)
- Queries (Read Operations)
into different models.
Each side can be optimized independently.
How Does It Work?
[Insert diagram here showing Write Model → Event Bus → Read Model]
Commands
|
v
Write Database
|
Event Bus
|
v
Read Database
^
|
Queries
Command Side
Responsible for:
- Create Order
- Update User
- Process Payment
Focuses on consistency.
Query Side
Responsible for:
- Search
- Reports
- Dashboards
Focuses on speed.
Example
Blog Platform
Write Side
Create Blog
Update Blog
Delete Blog
Stored in a relational database.
Read Side
Search Blogs
Trending Posts
Popular Authors
Stored in a denormalized database optimized for fast retrieval.
This allows search operations to remain extremely fast even under heavy traffic.
Benefits
Better Read Performance
Read models are optimized specifically for querying.
Independent Scaling
Read replicas can scale without affecting write operations.
Flexible Storage
Different databases can be used for read and write workloads.
Challenges
Eventual Consistency
Read data may not update immediately.
Additional Complexity
Need synchronization between read and write models.
More Infrastructure
Requires messaging systems and data pipelines.
Interview One-Liner
CQRS separates read and write operations into different models so that each can be optimized and scaled independently.
Quick Revision
| Pattern | Why | Example |
|---|---|---|
| Strangler Pattern | Migrate from Monolith to Microservices safely | E-commerce migration |
| Saga Pattern | Handle distributed transactions | Order + Inventory + Payment |
| CQRS | Scale reads and writes independently | Blog search, dashboards |
Key Takeaways
- Use Strangler Pattern when migrating a monolith gradually.
- Prefer Database Per Service for microservice independence and scalability.
- Use Saga Pattern when a transaction spans multiple services and databases.
- Use CQRS when read traffic is significantly higher than write traffic.
- Saga solves consistency problems.
- CQRS solves scalability problems.
- Strangler solves migration problems.
These three patterns are among the most frequently discussed topics in system design interviews because they address real-world challenges faced by large-scale distributed systems.