When and How to Split Monoliths into Microservices: Strategies, Principles, and Timing

Background

Micro‑services have become mainstream in recent years. With Docker containers and automated operations, they are easier to manage, giving micro‑service architectures a strong development opportunity.

Purpose of Splitting

Before splitting, understand the original purpose: simplifying complex problems that appear in a monolithic architecture as the product grows.

Problems of a Monolith

Development is simple and code is centrally managed.

Debugging targets a single application.

Only one codebase to maintain, saving operational manpower.

As features increase and teams grow, monolith drawbacks emerge:

Database connection limits become a bottleneck for scaling application servers.

Increased coupling leads to duplicated functionality, code conflicts, and extensive regression testing.

Build and deployment times grow from minutes to tens of minutes, reducing agility.

Micro‑service splitting can address these issues.

When to Split

Business scale: after market validation, typically during the growth stage of the product lifecycle.

Team size: around one hundred developers.

Technical reserve: DDD, service registry, configuration center, logging, CI/CD, monitoring, distributed scheduling, CAP theory, tracing, API gateway, etc.

Talent reserve: architects and developers experienced in micro‑service implementation.

R&D efficiency: noticeable decline in productivity.

Guiding Principles for Splitting

High cohesion, low coupling : each service should own its responsibilities only.

Closure principle (CCP) : changes to a service should not require modifications in other services.

Service autonomy & interface isolation : avoid strong dependencies, use standard interfaces to hide internal details.

Continuous evolution : start with a few services, iterate gradually, and avoid explosive growth.

Minimize impact on product iteration : split non‑core services first, keep core functionality stable.

Extensible service interfaces : design APIs with wrapper objects to allow parameter additions without breaking contracts.

Avoid circular and bidirectional dependencies : ensure clear boundaries and no shared generic functionality.

Splitting Strategies

Functional Dimension

Use Domain‑Driven Design (DDD) to define clear business boundaries:

Identify domain entities and value objects.

Determine aggregate roots and build aggregates.

Define bounded contexts based on business semantics.

Map each bounded context to a micro‑service, considering non‑functional factors.

Example: an e‑commerce transaction chain can be split into services such as order, payment, inventory, pricing, etc.

Non‑Functional Dimension

Extensibility : separate stable, reusable functions from frequently changing ones.

Reusability : extract common capabilities (authentication, rate limiting, logging) into shared services like an API gateway.

High performance : isolate performance‑critical modules (e.g., flash‑sale queue) or apply read‑write separation.

High availability : keep core services highly available while allowing non‑core services to have lower SLAs.

Security : deploy high‑security services in isolated zones (DMZ) to meet stricter compliance.

Heterogeneity : implement services in different languages when required by business constraints.

These dimensions are not mutually exclusive and can be combined as needed.

Service Merging

Over time, service granularity may become too fine‑grained, increasing operational cost. Merging multiple services into a service package reduces resource consumption while preserving micro‑service contracts for future re‑splitting.

Risks and Precautions

Do not fight unprepared battles : ensure the team has sufficient experience or conduct thorough technical proof‑of‑concepts before splitting.

Continuous correction : treat splitting as an evolving process; be ready to adjust boundaries as business knowledge deepens.

Be action‑oriented, not just theoretical : experiment early, learn from failures, and iterate quickly.

Micro‑service architecture also requires organizational adaptation to maintain independent teams for each service.