Principles and Guidelines for Splitting Microservices

1. Why Split Microservices

Monolithic architectures suffer from large codebases that are hard to maintain, performance issues that affect the whole system, and long build‑test‑deploy cycles that reduce delivery efficiency.

1.1 Shortcomings of a Monolith

Code size becomes massive, leading to IDE slowdown and frequent merge conflicts.

A performance problem in one part can degrade the entire system.

Every change requires rebuilding and testing the whole application, slowing down releases.

1.2 Risks of Over‑Splitting

Complex dependency graphs increase architectural understanding cost.

Excessive development effort; a single developer may need to modify many services.

Too many RPC calls degrade interface performance and stability.

Higher operational overhead for deployment, testing, and scaling.

Infrastructure libraries (JARs) become costly to upgrade.

2. Principles for Microservice Partitioning

2.1 Team Isolation Principle

Different teams own distinct domains and should not share microservices; strict isolation avoids cross‑team coupling.

2.2 Domain Isolation Principle

Separate services by business domains (e.g., order, product, marketing, settlement, payment, logistics). Sub‑domains may be grouped when complexity is low, but avoid creating a service per tiny sub‑domain.

2.3 The Three‑Person (Three Musketeers) Principle

Each microservice should be owned by three senior engineers (e.g., Alibaba P6/P7 level) who are familiar with the code and business, ensuring backup capability and reducing single‑point risk.

2.4 Read/Write Isolation Principle

High‑traffic read operations should be separated from write operations to prevent GC pressure and allow independent scaling, degradation, and circuit‑breaking strategies.

2.5 B/C‑Side Isolation Principle

Backend (B) and consumer (C) portals often require separate services to accommodate different user roles, processes, and future team splits.

2.6 Business Isolation Principle

Core business services should be isolated from less critical ones; non‑core services can share a microservice when appropriate.

2.7 External API Isolation Principle

Expose external HTTP APIs through a dedicated gateway or thin service that performs protocol translation, keeping internal business logic separate.

2.8 Minimal‑Change Principle

A developer should ideally modify no more than two services per feature to keep change scope manageable.

2.9 Unidirectional Dependency Principle

Services should depend on each other in only one direction; circular calls cause stack overflows and hinder independent deployment.

2.10 Importance Isolation Principle

Low‑importance or internal‑only services (e.g., operational tools) can be isolated to allow flexible deployment without affecting user‑facing systems.

2.11 Code Reuse Does Not Necessarily Mean Service Sharing

Common utilities (SMS, email, file handling) should be extracted into shared libraries (JARs) rather than bundled into a business service.

2.12 Per‑Person Service Count Principle

Recommended service counts based on team size: ≤5 members → ≤3 services; ≤10 members → ≤5 services; ≤15 members → 7‑8 services.

2.13 Forward‑Looking Design

Start with shared services when complexity is low, but be prepared to split as business grows; studying industry best practices helps avoid costly mistakes.

3. Hotspot Services Are Inevitable

Some services become “big mud balls” that many developers touch; attempting to split them often introduces more risk than benefit, so it is better to prevent such services from forming in the first place.