Various Approaches to Service Decomposition in Microservice Architecture

We know microservices are a concept without a precise definition, similar to design principles, and any division must be analyzed case by case; the following classifications are therefore only reference material.

Service splitting is considered difficult because of granularity: too large a grain makes splitting unnecessary, while too small a grain creates problems in aggregation, deployment, call chains, and debugging.

Decomposition Approaches

Approach One (Vertical and Horizontal Splitting – Hu Zhong, Sina Weibo)

Vertical Splitting : Split based on business domains; tightly related business functions form a microservice, while relatively independent functions become separate services.

Horizontal Splitting : Split based on common, independent functionalities that are called by multiple services and have independent resources.

Approach Two (Alibaba Perspective)

Service splitting should meet business needs, avoid defining boundaries by team to prevent “territorial” conflicts, and keep maintenance costs (people, resources, time) lower than before splitting.

Consider release frequency: isolate the 20% frequently changing parts and deploy the stable 80% separately, following the 80/20 principle.

Approach Three (Li Yunhua’s Expert Guidance)

Based on business logic: group responsibilities into separate services.

Based on stability: separate stable modules from frequently changing ones.

Based on reliability: group high‑reliability core modules together, low‑reliability ones separately.

Based on performance: isolate high‑performance modules (e.g., full‑text search, order processing) into dedicated services.

Summary of Approaches

All prioritize business logic as the primary factor.

They share similar views on stability, reliability, independence, and scalability.

Splitting should be multi‑criteria, not a single rule; specific situations require flexible combinations.

Additional Discussion

When applying these criteria, conflicts may arise, such as differing numbers of services (e.g., 3 vs 6) depending on team size; a rule of three people per service is suggested for balanced responsibility.

Team composition, service stability, and release strategies must be considered together to achieve a scalable, maintainable architecture.

© The content is sourced from the original author; for further discussion, readers are invited to join the architect community.