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