Reasonable Microservice Splitting: Problems, Principles, and Practical Guidelines

Hello everyone, I am Chen, the author of the "Spring Cloud Alibaba Practical Project" video tutorial covering Alibaba middleware, OAuth2 authentication, gray release, and distributed transactions.

What problems arise when splitting services?

Using an e‑commerce order‑inventory example, a monolithic app ensures strong consistency via a single database session, while splitting into microservices introduces communication across RPC boundaries, leading to potential data inconsistency due to failures, network issues, or business errors.

This illustrates a classic "complexity shift": the code complexity of a monolith moves to the communication complexity between services, without reducing overall system complexity.

According to the CAP theorem, a distributed system can only guarantee two of three properties—consistency, availability, and partition tolerance.

CAP defines the three guarantees:

Consistency : either return an error or the latest absolutely consistent data.

Availability : always return data (may be stale) without errors.

Partition tolerance : keep running despite internal data‑sync problems.

To address consistency, the industry uses mechanisms like BASE theory, distributed transaction models (XA, TCC, JTA), and categorises consistency requirements into strong, weak, or eventual consistency.

In practice, heavy distributed transactions are avoided; asynchronous scenarios use transactional messaging (RabbitMQ, Kafka, RocketMQ), while synchronous scenarios rely on business state machines to handle errors, retries, alerts, or manual intervention.

Ultimately, BASE theory guides production design.

Splitting microservices improves partition tolerance and availability but sacrifices the consistency advantage of monoliths, so splitting should be motivated by clear reasons.

How to split microservices reasonably?

After understanding the issues, consider the following approaches:

1. Split by single responsibility : isolate distinct business domains (e.g., user, product, inventory, marketing) into separate services with vertical database separation and high‑availability deployment.

2. Split by team organization (Conway's Law) : the system architecture mirrors the communication structure of the organization. The four laws of Conway's Law emphasize that communication patterns shape system design, and that small, autonomous teams (the “2‑pizza team”) enable better modularization.

Applying these laws suggests aligning each microservice with a dedicated team, ensuring high cohesion and low coupling.

3. Align system design with team size : large systems tend to be decomposed; small teams should avoid over‑splitting into many services.

4. Use MVP and iterative development : design minimal viable products, iterate, and keep the architecture elastic.

Key practical recommendations:

Improve communication tools (Slack, GitHub, Wiki) and keep responsibilities clear.

Adopt MVP design and iterative, elastic architecture.

Structure teams around business domains to achieve autonomous ownership and reduce cross‑team friction.

Maintain small, effective teams (around 7‑8 members) to minimize coordination overhead.

In summary, as long as the rationale is clear, communication is efficient, and operational capabilities keep pace, service splitting is generally justified.

Final note (please follow)

All of my articles are compiled into PDFs across three columns (Spring Cloud Advanced, Spring Boot Advanced, MyBatis Advanced). Access them by following the "Code Monkey Technical Column" public account and replying with the respective keywords.

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