When to revert to monolith in Microservices - Scalability & System Analysis

Scalability Analysis - When to revert to monolith

Growth Table: Microservices to Monolith

Users	System State	Challenges	What Changes
100 users	Microservices running smoothly	Low latency, easy deployment	Independent services, simple communication
10,000 users	Microservices with moderate complexity	Increased inter-service calls, some latency	Need for service discovery, monitoring
1,000,000 users	Microservices with high complexity	High network overhead, debugging hard	Complex orchestration, data consistency issues
100,000,000 users	System struggles with microservices overhead	Latency spikes, deployment delays, high cost	Consider simplifying architecture, possible monolith

First Bottleneck

The first bottleneck when scaling microservices is often the network communication overhead between services. As the number of services grows, the number of calls between them increases, causing latency and complexity. This slows down response times and makes debugging difficult.

Scaling Solutions

• Optimize communication: Use asynchronous messaging or batch calls to reduce overhead.
• Service consolidation: Merge tightly coupled services to reduce network calls.
• Revert to monolith: When microservices add too much complexity and latency, combine services into a single deployable unit to simplify communication and debugging.
• Use caching: Cache frequent data to reduce calls between services.
• Monitoring and tracing: Implement tools to understand call patterns and identify hotspots.

Back-of-Envelope Cost Analysis

Assuming 1 million users generate 10 requests per second each, total requests = 10 million QPS.

Each microservice call adds network latency (~10ms) and CPU overhead.

Network bandwidth and CPU usage increase with inter-service calls, raising infrastructure costs.

Reverting to monolith reduces network calls, lowering latency and cost.

Interview Tip

Start by explaining the benefits of microservices at small scale. Then describe how complexity and network overhead grow with scale. Identify the first bottleneck clearly. Finally, discuss when and why reverting to a monolith makes sense, focusing on simplicity and performance.

Self Check

Your microservices system handles 1000 QPS. Traffic grows 10x to 10,000 QPS. You notice latency spikes due to many inter-service calls. What do you do first?

Answer: Consider consolidating some services to reduce network overhead or optimize communication patterns before scaling infrastructure.

Key Result

Microservices work well at small to medium scale, but as user count and inter-service calls grow, network overhead becomes the first bottleneck. Reverting to a monolith can simplify communication and improve performance when microservices complexity 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