Backend Development 8 min read

Various Approaches to Microservice Decomposition

The article examines microservice architecture as an abstract concept and presents three practical decomposition strategies—vertical/horizontal business split, business‑driven and team‑oriented considerations, and criteria based on logic, stability, reliability and performance—while also discussing cost, release frequency, and team size implications.

Architect
Architect
Architect
Various Approaches to Microservice Decomposition

Microservice architecture is an abstract design principle without a strict definition, making service decomposition a nuanced task that depends on concrete business scenarios.

Decomposition Approach 1 – Vertical and Horizontal Split (Weibo expert Hu Zhong): Vertical splitting groups services by business domain based on the closeness of business relationships, while horizontal splitting isolates common, independent functions that are used by multiple services.

Decomposition Approach 2 – Business‑Driven and Team‑Oriented (Alibaba perspective): Emphasizes aligning services with business independence and professional boundaries, avoiding team‑based boundaries that cause “territorial” conflicts. It also stresses that post‑split maintenance costs (people, resources, time) must be lower than before, and that release frequency should follow an 80/20 principle, extracting frequently changing parts into separate services.

Decomposition Approach 3 – Criteria from a Senior Expert (Li Yunhua): Proposes multiple axes for splitting:

Based on business logic: services correspond to distinct business responsibilities.

Based on stability: stable modules are grouped together, while volatile modules are isolated.

Based on reliability: high‑reliability core modules are clustered, low‑reliability ones are separated.

Based on performance: performance‑critical modules (e.g., search, checkout) become independent services.

The article concludes that no single standard exists; the best split combines several criteria and must be adapted to the specific context.

Additional Considerations – Team Size: A rule of thumb suggests three developers per service to ensure redundancy, balanced workload, and effective technical discussion, while larger teams may justify more granular splits.

Overall, the piece provides a comparative overview of microservice decomposition methods, highlighting the importance of multi‑dimensional analysis, cost awareness, and organizational alignment.

backend architecturemicroservicesteam organizationsoftware designservice decomposition
Architect
Written by

Architect

Professional architect sharing high‑quality architecture insights. Topics include high‑availability, high‑performance, high‑stability architectures, big data, machine learning, Java, system and distributed architecture, AI, and practical large‑scale architecture case studies. Open to ideas‑driven architects who enjoy sharing and learning.

0 followers
Reader feedback

How this landed with the community

login Sign in to like

Rate this article

Was this worth your time?

Sign in to rate
Discussion

0 Comments

Thoughtful readers leave field notes, pushback, and hard-won operational detail here.