How to Split Microservices: 3 Expert Strategies for Effective Service Decomposition

1. Splitting Approaches

1.1 Approach One

Weibo microservice expert Hu Zhongxiang proposes a simple vertical and horizontal division.

Vertical splitting is based on business dimensions. Services are separated according to the degree of business correlation; tightly related business functions become a single microservice, while relatively independent functions are split into separate services.

Horizontal splitting focuses on common and independent functionalities. If a function is shared by multiple services and its resources are independent, it should be extracted as a separate service.

Vertical groups business‑tight services together; horizontal groups function‑independent services together. The question remains: if splitting seems simple, do you have the confidence to actually do it?

1.2 Approach Two

Alibaba practitioners view splitting from a comprehensive perspective, overlapping with the previous dimensions.

2.1 Align with business needs – Ensure service boundaries reflect business independence and expertise, avoiding team‑driven boundaries that cause “territorial fights” and damage trust.

2.2 Maintenance cost should be lower after splitting – Consider human, material, and time costs; if cost outweighs benefit, advanced technology becomes a hindrance.

2.3 Organizational structure must adapt – Independent teams should own the services they maintain, shifting from traditional product‑front‑back divisions to service‑centric staffing.

2.4 Splitting improves scalability – Separate services with different scalability requirements, such as a dedicated full‑text search service, to reduce cost and increase efficiency.

2.5 Consider release frequency – Apply an 80/20 rule: isolate the 20% of frequently changing parts, deploy the stable 80% separately, reducing release side‑effects.

When conflicting splits arise, prioritize the higher‑weight criteria.

1.3 Approach Three

Senior architect Li Yunhua outlines four dimensions:

3.1 Business‑logic based – Group responsibilities with the same business scope into a single service; this is the most fundamental criterion.

3.2 Stability based – Separate stable, rarely‑changed modules from unstable, frequently‑changed ones (e.g., logging, monitoring).

3.3 Reliability based – Cluster high‑reliability core modules together, and low‑reliability non‑core modules together, avoiding a single point of failure.

3.4 Performance based – Isolate high‑performance demanding modules (e.g., full‑text search, order processing, flash sales) into their own services.

2. Summary of Approaches

All approaches place business logic at the forefront.

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

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

3. Side Notes

Applying these criteria in practice may lead to conflicts. For example, splitting by business could yield either three services (product, transaction, user) or six services (product, order, payment, logistics, buyer, seller). The appropriate granularity depends on team size—three services for a nine‑person team, six for an eighteen‑person team.

Team composition matters: a service should ideally be handled by three engineers. One person creates a single point of failure; two people leave one overloaded when one is absent; three provides redundancy, diverse viewpoints, and balanced workload.

The “three‑person rule” is a baseline; actual staffing may vary over a service’s lifecycle.

Source: https://www.cnblogs.com/jackyfei/p/10856427.html