How to Effectively Split a Large System into Microservices?

For a large system, from what perspective should microservice splitting be done?

First determine the approximate number of microservices; too many increase maintenance cost, so stay within the team's capacity. After deciding the number, consider how to split.

Service Granularity

Best to split based on team size: ideally one microservice per three developers. For example, a six‑person team can be divided into two services, and when the team grows to twelve, split into four.

Benefits of a three‑person team:

Three people per service provide appropriate understanding, division, and efficiency.

From a management perspective, a three‑person unit is stable; if one member is absent, the remaining two can still support it, unlike a two‑person unit.

From a technical growth perspective, three people can discuss effectively and reach consensus quickly; two may stick to personal opinions, and four may have disengaged participants.

Splitting Methods

1. Business‑Logic‑Based Splitting

Identify business modules by responsibility and split each into an independent service.

Example: an e‑commerce system can be divided into product, transaction, and user services (three) or product, order, payment, shipping, buyer, and seller services (six).

Both approaches are valid; the difference lies in quantity, which should be decided using the granularity principle and team size.

2. Scalability‑Based Splitting

Sort modules by stability; mature, low‑change modules become stable services , while frequently changing modules become volatile services .

Stable services can be coarser; even loosely related logic can share a service (e.g., logging and upgrade services).

Volatile services should be finer, but keep an eye on the total number of services.

This approach aims to accelerate iteration while isolating changes from stable functionality.

3. Reliability‑Based Splitting

Separate high‑reliability core services from low‑reliability non‑core services, ensuring core services achieve high availability.

Benefits:

Avoid non‑core failures affecting core services.

Simplify high‑availability solutions for core services.

Reduce high‑availability costs, as isolated core services consume fewer resources.

4. Performance‑Based Splitting

Extract modules under heavy performance pressure to prevent impact on other services and simplify optimization.

Example: a flash‑sale queue in an e‑commerce platform can be isolated as its own service.

Summary

These splitting strategies are not mutually exclusive; they can be combined based on actual needs. For instance, system X might be divided into services A (reliability), B (performance), and C/D/F (scalability), resulting in six services overall.

Content compiled from “From Zero Learn Architecture”.