When to revert to monolith in Microservices - System Design Exercise

Design: Decision Framework for Reverting Microservices to Monolith

Focus on architectural decision-making and transition strategy from microservices back to monolith. Out of scope: detailed code migration or specific technology implementations.

Functional Requirements

FR1: Identify scenarios where a microservices architecture causes more harm than good

FR2: Define criteria to decide when to consolidate services into a monolith

FR3: Ensure system remains maintainable, scalable, and performant after reversion

FR4: Support smooth transition with minimal downtime and data loss

Non-Functional Requirements

NFR1: System must handle up to 10,000 concurrent users

NFR2: API response latency should remain under 300ms p99

NFR3: Availability target of 99.9% uptime

NFR4: Transition should not disrupt ongoing business operations

Think Before You Design

Questions to Ask

❓ Question 1

❓ Question 2

❓ Question 3

❓ Question 4

❓ Question 5

❓ Question 6

❓ Question 7

Key Components

API Gateway or Load Balancer

Service Registry and Discovery

Centralized Logging and Monitoring

Database(s) - distributed vs monolithic

CI/CD pipelines for deployment

Message queues or event buses

Design Patterns

Strangler Fig pattern for gradual migration

Database consolidation strategies

Circuit Breaker and Bulkhead for fault tolerance

Modular Monolith design

Feature toggles for controlled rollout

Reference Architecture

 +-------------------+       +-------------------+       +-------------------+
 |   Client / UI     | <---> |   API Gateway     | <---> | Microservices Set |
 +-------------------+       +-------------------+       +-------------------+
           |                                                        |
           |                                                        |
           |                                                        v
           |                                              +-------------------+
           |                                              |  Distributed DBs   |
           |                                              +-------------------+
           |
           |  (Revert to Monolith)
           v
 +-------------------+       +-------------------+
 |   Client / UI     | <---> |   Monolithic App  |
 +-------------------+       +-------------------+
                                   |
                                   v
                          +-------------------+
                          |   Single Database  |
                          +-------------------+

Components

API Gateway

Nginx, Kong, or AWS API Gateway

Routes client requests to appropriate microservices or monolith endpoints

Microservices Set

Docker containers, Kubernetes

Independent services handling specific business capabilities

Distributed Databases

Multiple PostgreSQL or NoSQL instances

Stores data partitioned by service ownership

Monolithic Application

Single deployable app (e.g., Spring Boot, Django)

Consolidated codebase handling all business logic

Single Database

Relational DB like PostgreSQL or MySQL

Centralized data storage for monolith

CI/CD Pipeline

Jenkins, GitHub Actions

Automates build, test, and deployment processes

Request Flow

1. Client sends request to API Gateway.

2. In microservices mode, API Gateway routes request to relevant microservice.

3. Microservice processes request, may call other services or databases.

4. Response is sent back through API Gateway to client.

5. In monolith mode, API Gateway routes request to monolithic app.

6. Monolithic app processes request internally and queries single database.

7. Response is sent back to client via API Gateway.

8. During transition, some requests may be routed to microservices and others to monolith using Strangler Fig pattern.

Database Schema

Entities: User, Order, Product, Payment Relationships: - User 1:N Order - Order N:1 Product - Order 1:1 Payment In microservices, each service owns its schema (e.g., Order service owns Order and Payment tables). In monolith, all entities reside in a single database schema with foreign keys enforcing relationships.

Scaling Discussion

Bottlenecks

High inter-service communication latency causing slow responses

Complex deployment pipelines increasing release time

Data consistency issues due to distributed transactions

Operational overhead managing many services

Scaling database shards independently causing uneven load

Solutions

Revert to monolith to reduce network calls and simplify data access

Adopt modular monolith design to keep code organized but deploy as one unit

Consolidate databases to avoid distributed transaction complexity

Simplify CI/CD pipelines for faster deployment

Use caching and load balancing to improve performance

Interview Tips

Time: Spend 10 minutes understanding microservices challenges, 15 minutes discussing criteria and transition approach, 10 minutes on architecture and data flow, 10 minutes on scaling and trade-offs.

Explain why microservices might not always be best for small teams or simple domains

Discuss operational complexity and latency as key pain points

Describe gradual migration strategies like Strangler Fig pattern

Highlight importance of data consistency and deployment simplicity

Show understanding of trade-offs between modularity and complexity

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