From Monolith to Microservices: When and How to Adopt Distributed Architecture

1. The Past of Monolithic Architecture

(1) Monolithic Architecture Overview

Monolithic architecture, also called a monolith, designs an entire application as a single deployable unit. All functional modules—frontend, business logic, data storage, databases, third‑party services—are bundled in one codebase and communicate via function calls or shared memory.

In early software development this style was favored for its simplicity. A small e‑commerce site could house UI, backend logic, and database operations in one repository, making version control, debugging, and team collaboration straightforward, and allowing deployment of the whole system with a single package.

(2) Advantages of Monolithic Architecture

Simplicity : The design is easy to understand and maintain, especially for beginners or small teams, because all code lives under one “roof”.

High development efficiency : Adding new features or iterating is fast since developers work in a single codebase and module interactions are direct.

Easy deployment : The entire application can be packaged and deployed as one unit without coordinating multiple services.

Data consistency : Running in a single process makes transaction management and data consistency simpler.

(3) Limitations of Monolithic Architecture

Limited scalability : As business grows, tightly coupled modules make it hard to extend or improve performance of a single component without affecting the whole system.

Hard to maintain : Larger codebases become less readable; new developers face steep learning curves, and lack of clear module boundaries hampers maintenance.

Deployment and upgrade inconvenience : Every change requires rebuilding and redeploying the whole application, leading to longer downtime and higher risk during updates.

2. Rise of Distributed Architecture

(1) Background of Distributed Architecture

With the explosive growth of internet traffic and user bases, monolithic systems struggled to handle high‑concurrency scenarios. Large e‑commerce platforms that started with a monolith faced bottlenecks during peak events like "Double‑Eleven" or "618", where a single tightly‑coupled codebase could not scale horizontally, prompting the shift to distributed designs.

(2) Core Principles of Distributed Architecture

Distributed systems split a large monolith into relatively independent services, enabling separate development, deployment, and scaling. Common principles include:

N+1 Design : Deploy at least two (often three) instances of a stateless service to provide redundancy.

Rollback Design : Keep historical releases or feature switches so a faulty version can be reverted quickly.

Feature Toggle : Hide new functionality behind switches that can be turned on/off without redeploying.

Monitoring Design : Define key metrics early and adopt metrics‑driven development to observe system health in real time.

(3) Advantages of Distributed Architecture

High availability: Independent services run on different nodes, so a failure of one does not bring down the whole system.

High scalability: Each service can be horizontally scaled according to its load, avoiding full‑system redeployment.

Fault tolerance: Failures are isolated, and fallback mechanisms keep the overall system stable.

Improved code readability: Smaller, purpose‑specific services are easier to understand and maintain.

Real‑world example: During a major sales event, an e‑commerce platform can add more instances of the order‑processing service without touching the user or product services, ensuring smooth checkout despite traffic spikes.

3. Key Steps from Monolith to Distributed

(1) Database Layer Transformations

Initially, databases are co‑located with the application, which is simple for small projects. As traffic grows, this tight coupling creates bottlenecks, leading to:

Isolation deployment: Separate database servers from application servers to utilize resources efficiently.

Master‑slave replication: Write operations go to the master, reads are distributed to slaves, improving read throughput.

Read‑write separation: Route writes to the master and reads to multiple replicas, further scaling read‑heavy workloads.

Vertical sharding: Split tables by business domain into different databases (e.g., separate user, order, product databases).

Horizontal sharding: Partition large tables by key ranges (e.g., user‑ID ranges) across multiple instances to reduce single‑table pressure.

These changes boost performance and prepare the data layer for distributed services.

(2) Application Layer Splitting and Optimization

Growing business complexity drives the decomposition of a monolith into subsystems or microservices. Typical steps include:

Identify logical boundaries and extract independent subsystems (e.g., user management, product catalog, order processing).

Adopt microservices: Each service owns its own codebase, database, and technology stack, communicating via lightweight protocols such as RESTful APIs or message queues.

Extract common functionalities (authentication, authorization) into shared services to avoid duplication.

Scale resources per service: Increase instances for high‑load services (e.g., order processing during sales) while reducing them for low‑traffic services.

This approach improves maintainability, accelerates feature delivery, and reduces the impact of changes.

(3) Introduction of Caching and Load Balancing

Caching (e.g., Redis) stores frequently accessed data in memory, dramatically reducing database load during high‑concurrency periods. Strategies such as cache‑aside, write‑through, and proper expiration policies mitigate cache‑penetration, cache‑stampede, and cache‑avalanche problems.

Load balancers distribute incoming requests across multiple service instances using algorithms like round‑robin, least‑connections, weighted round‑robin, or IP‑hash. They also provide health checks and automatic failover, ensuring continuous availability even when individual nodes fail.