Microservice Splitting Strategies: Expert Perspectives and Practical Guidelines

Hello everyone, I’m Chen, the author of this article.

Microservices are a conceptual paradigm without a strict definition; therefore, service partitioning is subjective and should be analyzed case by case. The following discussion presents three expert "splitting postures" that reflect different experiences and viewpoints.

Splitting Postures

Posture One – Sina Weibo microservice expert Hu Zhong’s vertical and horizontal dimensions (simple and blunt)

1. Vertical splitting

Divide based on business domains: tightly related business functions stay together in one microservice, while relatively independent functions are split into separate services.

2. Horizontal splitting

Divide based on common, independent capabilities that are invoked by multiple services and have independent resources.

Posture Two – Alibaba’s comprehensive view (some overlap with the above)

1. Align service splitting with business needs

Consider business independence and professionalism, avoid defining service boundaries by team structures to prevent “territorial” conflicts.

2. Post‑splitting maintenance cost should be lower than before

Costs include manpower, material, and time; the benefit must outweigh the investment.

3. Consider release frequency

Separate the 20% frequently changing parts from the 80% stable parts (the 8/2 principle) to reduce release side‑effects.

Posture Three – Senior architect Li Yunhua’s four criteria

1. Business logic

Group responsibilities with the same business logic into a single service.

2. Stability

Separate stable modules (e.g., logging, monitoring) from frequently changing ones.

3. Reliability

Cluster high‑reliability core modules together, and low‑reliability non‑core modules together.

4. Performance

Isolate high‑performance demanding modules (e.g., full‑text search, flash‑sale) into dedicated services.

Summary of Postures

All approaches prioritize business logic first.

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

Splitting should be a multi‑criteria decision, not a single rule; combine methods flexibly.

Recommended Java Engineer Technical Guide: https://github.com/chenjiabing666/JavaFamily (please star it!)

Side Note

When applying these criteria in practice, conflicts may arise, such as differing granularity (e.g., 3 services vs. 6 services for an e‑commerce system). The appropriate number depends on team size—9 people may suit 3 services, while 18 people may handle 6 services.

Team Configuration – The “Three Musketeers”

Why three backend engineers per service? One person is a single point of failure; two provide backup but still high pressure; three offer redundancy, balanced workload, and diverse viewpoints, making it a stable baseline.

Recommended Java Engineer Technical Guide: https://github.com/chenjiabing666/JavaFamily (please star it!)

Final Note (Please Follow)

If this article helped you, please like, view, share, and bookmark—it fuels my continued writing.

My Knowledge Circle is also open; reply with the keyword to get a 30‑yuan coupon for premium content such as Spring full‑stack practice, massive data sharding, DDD microservice series, and architecture lectures.