Microservice Splitting Strategies: Purpose, Timing, Principles, Granularity, and Risks

Background: Microservices have become popular, driven by container and DevOps advances, prompting many companies to consider breaking monoliths into services.

Purpose of Splitting: The goal is to simplify complex problems, improve scalability, reduce coupling, and enhance development and operational efficiency as the system grows.

When to Split: Split when business scale reaches a mature growth stage, team size approaches around a hundred developers, technical foundations (DDD, service registry, monitoring, etc.) are ready, and development efficiency noticeably declines.

Guiding Principles: 1) High cohesion and low coupling within a service; 2) Closure principle (CCP) – changes stay inside the service; 3) Service autonomy and interface isolation; 4) Continuous evolution with incremental granularity; 5) Minimal impact on product iteration; 6) Extensible service interfaces; 7) Avoid circular and bidirectional dependencies.

Granularity Considerations: The "bow‑arrow" principle balances business complexity and team size, while the "three musketeers" principle suggests roughly three developers per service for optimal knowledge sharing, backup, and decision‑making.

Splitting Strategies: • Functional dimension – use Domain‑Driven Design to identify entities, aggregates, bounded contexts, and map each context to a service. • Non‑functional dimension – consider extensibility, reusability, performance, high availability, security, and heterogeneity when further dividing services.

Merging Services: Over‑splitting can lead to operational overhead; merging services (or packaging multiple services) may be necessary when resource constraints or team size change, while preserving service boundaries for future re‑splitting.

Risks and Recommendations: Ensure the team has sufficient experience or conduct thorough technical proof‑of‑concepts, continuously reassess service boundaries, adopt a pragmatic action‑oriented approach, and build supporting infrastructure (service governance, data migration tools, etc.) to reduce the cost of adjustments.

The article references the book "Continuous Evolution of Cloud Native: Best Practices for Microservices Architecture" and provides illustrative diagrams throughout.