When to revert to monolith in Microservices - Architecture Diagram

System Overview - When to revert to monolith

This system explains when a software project using microservices should consider reverting back to a monolithic architecture. Key reasons include complexity overhead, deployment difficulties, and performance issues. The goal is to balance scalability with simplicity for maintainable and efficient development.

Architecture Diagram

User
  |
  v
Load Balancer
  |
  v
API Gateway
  |
  +---------------------+---------------------+
  |                     |                     |
Service A            Service B             Service C
  |                     |                     |
Database A           Database B            Database C
  |
Cache

-- Reverted Monolith Architecture --
User
  |
  v
Load Balancer
  |
  v
Monolithic Service
  |
  v
Single Database
  |
  v
Cache

Components

User

user

End user interacting with the system

Load Balancer

load_balancer

Distributes incoming requests evenly to backend services

API Gateway

api_gateway

Routes requests to appropriate microservices and handles cross-cutting concerns

Service A

service

Handles a specific business capability in microservices architecture

Service B

service

Handles another business capability in microservices architecture

Service C

service

Handles another business capability in microservices architecture

Database A

database

Stores data for Service A

Database B

database

Stores data for Service B

Database C

database

Stores data for Service C

Cache

cache

Speeds up data access for frequently requested data

Monolithic Service

service

Single combined service handling all business logic after reverting

Single Database

database

Unified database storing all data in monolith

Request Flow - 18 Hops

User → Load Balancer

Load Balancer → API Gateway

API Gateway → Service A

Service A → Cache

Cache → Service A

Service A → Database A

Database A → Service A

Service A → API Gateway

API Gateway → Load Balancer

Load Balancer → User

User → Load Balancer

Load Balancer → Monolithic Service

Monolithic Service → Cache

Cache → Monolithic Service

Monolithic Service → Single Database

Single Database → Monolithic Service

Monolithic Service → Load Balancer

Load Balancer → User

Failure Scenario

Component Fails:API Gateway

Impact:All requests to microservices fail, causing system downtime

Mitigation:Use multiple API Gateway instances with failover and health checks to avoid single point of failure

Architecture Quiz - 3 Questions

Why might a team choose to revert from microservices to a monolith?

A To reduce complexity and simplify deployment

B To increase the number of databases

C To add more load balancers

D To separate business logic into more services

Design Principle

This architecture highlights the trade-off between microservices and monoliths. Microservices offer scalability and separation but add complexity and overhead. Reverting to a monolith can simplify deployment, reduce latency, and improve maintainability when the overhead outweighs benefits.

Practice

1. Which of the following is a common reason to revert from microservices back to a monolith?

easy

A. When you want to increase the number of services for better modularity

B. When the system needs to handle more users simultaneously

C. When you want to add more independent teams to work on the project

D. When microservices cause too much complexity and slow down development

Solution

1. Step 1: Understand microservices complexity

   Microservices can add overhead in communication and deployment, increasing complexity.

2. Step 2: Identify when to simplify

   If complexity slows development or causes performance issues, reverting to monolith helps.

3. Final Answer:

   When microservices cause too much complexity and slow down development -> Option D

4. Quick Check:

   Complexity and slow development = revert to monolith [OK]

Hint: Choose option mentioning complexity or slow development [OK]

Common Mistakes:

• Confusing scalability needs with reverting reasons
• Thinking more services always improve modularity
• Assuming more teams mean revert to monolith

2. Which syntax correctly describes a scenario to revert to monolith in a system design document?

easy

A. If (microservices_complexity > threshold) then revert_to_monolith()

B. while (services_count < max) { add_service(); }

C. deploy(microservices) if performance is good

D. scale(monolith) when load increases

Solution

1. Step 1: Analyze the condition for reverting

   The condition to revert is when microservices complexity exceeds a limit.

2. Step 2: Match syntax to scenario

   If (microservices_complexity > threshold) then revert_to_monolith() correctly uses a conditional to revert when complexity is high.

3. Final Answer:

   If (microservices_complexity > threshold) then revert_to_monolith() -> Option A

4. Quick Check:

   Condition on complexity triggers revert = If (microservices_complexity > threshold) then revert_to_monolith() [OK]

Hint: Look for condition checking complexity before revert [OK]

Common Mistakes:

• Choosing loops or unrelated deployment commands
• Ignoring the revert condition in syntax
• Confusing scaling with reverting

3. Given a microservices system with high network latency causing slow responses, what is the likely output of reverting to a monolith?

medium

A. Reduced network overhead and faster response times

B. Increased network calls and slower response times

C. More complex deployment pipelines

D. Increased service discovery failures

Solution

1. Step 1: Understand network latency impact

   Microservices communicate over network, causing latency and slow responses.

2. Step 2: Effect of reverting to monolith

   Combining services reduces network calls, lowering latency and improving speed.

3. Final Answer:

   Reduced network overhead and faster response times -> Option A

4. Quick Check:

   Less network calls = faster responses [OK]

Hint: Revert reduces network calls, so responses get faster [OK]

Common Mistakes:

• Thinking reverting increases network calls
• Confusing deployment complexity with runtime latency
• Assuming service discovery issues increase after revert

4. You have a microservices system with many small services causing deployment failures. Which fix correctly reverts to a monolith?

medium

A. Split services further to isolate failures

B. Combine services into a single deployable unit

C. Add more network retries for service calls

D. Increase the number of service instances

Solution

1. Step 1: Identify deployment failure cause

   Many small services increase deployment complexity and failure risk.

2. Step 2: Correct revert action

   Combining services into one unit simplifies deployment and reduces failures.

3. Final Answer:

   Combine services into a single deployable unit -> Option B

4. Quick Check:

   Combine services to simplify deployment [OK]

Hint: Fix deployment by combining services into one unit [OK]

Common Mistakes:

• Splitting services more instead of combining
• Adding retries doesn't fix deployment complexity
• Scaling instances doesn't solve deployment failures

5. A company has 20 microservices but faces slow feature delivery and high operational costs. What is the best approach to decide if reverting to a monolith is suitable?

hard

A. Add more microservices to distribute workload evenly

B. Immediately merge all services into one monolith to reduce costs

C. Evaluate team size, deployment complexity, and performance bottlenecks before deciding

D. Ignore operational costs and focus only on scaling microservices

Solution

1. Step 1: Analyze factors affecting delivery and costs

   Team size, deployment complexity, and performance issues impact delivery speed and costs.

2. Step 2: Make informed decision

   Evaluating these factors helps decide if reverting to monolith improves simplicity and efficiency.

3. Final Answer:

   Evaluate team size, deployment complexity, and performance bottlenecks before deciding -> Option C

4. Quick Check:

   Balanced evaluation guides revert decision [OK]

Hint: Assess team and complexity before reverting [OK]

Common Mistakes:

• Rushing to merge without analysis
• Adding more services without solving issues
• Ignoring costs and focusing only on scaling