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.