When Should You Split or Merge Microservices? A Practical Guide

Introduction

Microservice architecture decomposes a monolithic system into independent services that can be deployed, scaled, and maintained separately. While this improves flexibility, uncontrolled splitting and merging increase system complexity.

Background

Microservices are a set of small services that together implement a larger application. The definition of “small” is subjective, leading to disagreements about when and how to split.

Problems of Improper Service Splitting

Increased communication and coordination complexity.

Tangled service dependencies causing conflicts.

Higher latency and reduced throughput due to long network call chains.

More difficult deployment and maintenance as the number of services grows.

Higher integration testing and deployment cost.

Fault propagation where a single service failure can affect the whole system.

Call Chain Analysis

The number of possible direct calls grows quadratically: with N services there are N × (N-1) potential calls.

For three services there are six possible call paths:

For five services the number rises to twenty:

Impact 1 – Repeated Calls

When multiple services invoke the same downstream service repeatedly, traffic is amplified, overloading the target service.

Impact 2 – Circular Dependency

Mutual dependencies create unclear relationships, making fault isolation difficult and causing resource‑consumption loops.

Impact 3 – Chaotic Call Chains

Long, tangled call chains obscure request flow, hinder debugging, and reduce iteration efficiency.

Governance Strategies

Repeated Calls

Use tracing tools to detect duplicate invocations, then refactor business logic to consolidate calls, employ caching, and encapsulate shared functionality in reusable libraries.

Circular Dependency

Re‑examine the layered architecture, clearly define service responsibilities, and ensure higher‑level services depend only on lower‑level services, eliminating cycles.

Chaotic Call Chains

Apply domain‑driven design to identify bounded contexts, define clear responsibilities, limit team size per service (e.g., the “two‑pizza rule”), and enforce a direction where upper‑layer services may depend on lower‑layer services but not vice‑versa.

Service Splitting and Merging

Periodically review service boundaries in response to evolving business needs and organizational changes. Decide whether to split further, keep as is, or merge services to balance granularity and manageability.

Conclusion

Before a microservice transformation, assess the current system, confirm the need for decomposition, and proceed incrementally with strong architectural governance. Learning from internal and external experiences helps avoid common pitfalls.

Code example

相关阅读：