Microservice Splitting Strategies: Three Approaches and Practical Considerations

Microservice Splitting Strategies

Microservices are an abstract concept without strict definitions; the article presents three expert‑derived splitting “postures” and discusses their advantages, trade‑offs, and practical implications such as team size, maintenance cost, scalability, stability, reliability and performance.

1. First posture – vertical and horizontal splitting

Vertical splitting groups services by business domain, using the closeness of business logic as the criterion: tightly related business functions form a single service, while relatively independent functions are split into separate services.

Horizontal splitting groups services by common, independent functionality that is called by multiple services and has independent resources, emphasizing reuse and decoupling.

2. Second posture – business‑driven, cost‑aware, organizational considerations

Align service boundaries with business needs rather than team boundaries to avoid territorial conflicts.

Ensure that post‑split maintenance cost (people, time, resources) is lower than before the split.

Adapt the organizational structure so each service is owned by a relatively independent team.

Improve system scalability by separating services with different scalability requirements (e.g., search services).

Consider release frequency: extract the frequently changing 20% of functionality while keeping the stable 80% separate, reducing release side‑effects.

3. Third posture – based on responsibility, stability, reliability and performance

Group modules by responsibility scope; modules with the same responsibilities become a single service.

Separate stable modules from those that change frequently.

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

Isolate high‑performance components (e.g., full‑text search, checkout) into dedicated services.

The article concludes that there is no absolute standard for service decomposition; the appropriate split depends on business logic, stability, reliability, performance, team size and other contextual factors.