Why Microservices? Problems Solved, Challenges Faced, and Core Principles Explained

We need microservice architecture to solve specific problems that arise as systems grow; this article discusses the issues addressed by microservices, the challenges they bring, and their core conceptual essence.

1. Early Service Architecture

The diagram shows a typical layered service architecture:

Client: Browser web or app callers. Application Layer: Implements business logic, fetches data from upstream data layers, and returns HTML/JSON/files to downstream clients. Data‑Cache Layer: Improves data access performance. Data‑Database Layer: Persists data.

2. Problems with Monolithic Architecture

1. Heavy Monolithic Model In e‑commerce systems, a single application would need to handle user login, product browsing, ordering, checkout, payment, and order queries, making it overly bulky.

2. Traffic and Concurrency Limits When daily active users exceed millions or QPS reaches thousands, a monolith may struggle to sustain the load.

3. High Iteration Frequency Frequent business changes (multiple releases per week or daily) force full‑system deployments, even for unchanged modules.

4. Poor Scalability Rapid growth demands horizontal scaling, which microservices facilitate more easily.

5. Tight Coupling and Dependencies Highly coupled modules and complex dependencies make maintenance and upgrades difficult.

6. Lack of Fault Isolation and Resilience A failure in one module can affect the entire system.

3. Evolution of Microservice Architecture

The above problems stem from expanding functionality and traffic that strain monolithic designs; microservice evolution offers a path to address them.

3.1 Business‑Logic Based Splitting

Applying the single‑responsibility principle, we group related business functions into service units.

Domain Model Splitting For example, an e‑commerce platform can be divided into user account, product, order, customer, and logistics subsystems, each forming an independent service.

User‑Group Splitting Separate services based on distinct user roles, such as teachers and students in an education system, which reduces coupling and balances traffic.

3.2 Scalability‑Based Splitting

Distinguish between stable (unchanging) and volatile (frequently changing) parts. According to the 80/20 rule, roughly 20% of modules (e.g., operations, activities) change often, while the remaining 80% (user info, product info, logistics) remain stable. The volatile parts are isolated for independent scaling.

3.3 Reliability‑Based Splitting

Core Module Isolation Critical services such as MySQL, Redis, account, and payment are placed in dedicated clusters with top‑tier resources, ensuring that failures in less critical modules do not impact core services.

Primary‑Secondary Link Splitting Identify primary business flows (e.g., product search → detail page → cart → checkout → payment) and allocate the best resources to them, while secondary flows receive lower priority, enhancing fault tolerance.

3.4 Performance‑Driven Splitting

For ultra‑high‑concurrency scenarios such as points bidding, flash sales, or limited‑time purchases, isolate these workloads into separate services to meet stringent latency requirements.

4. Costs of Microservice Adoption

Inherent Complexity of Distributed Systems Microservices introduce performance overhead and reliability challenges inherent to distributed architectures.

Dependency Management and Testing Beyond unit tests, integration testing must cover entire service chains.

Configuration and Version Management Requires robust versioned configuration and environment handling.

Automated Deployment Pipelines Effective CI/CD, service mesh, and containerization are essential.

Higher DevOps Demands Developers must own the full service lifecycle, including deployment, tracing, and monitoring.

Escalating Operations Costs Each microservice needs independent configuration, deployment, monitoring, and logging, leading to exponential operational overhead.

5. Essence of Microservice Architecture

The final state of a microservice system often looks like the diagram below:

Key principles include:

Risk Isolation: High autonomy and isolation prevent low‑priority services from affecting high‑priority ones.

Divide‑and‑Conquer: Individual service throughput is limited; splitting services breaks scaling ceilings and supports global traffic.

Single Responsibility: The monolith evolves into fine‑grained services each with a single responsibility.