How to Prepare and Execute a Successful Microservice Migration

Earlier we learned about the panoramic architecture of microservices, understanding their advantages over traditional monolithic systems and the trend toward service-oriented designs.

For new projects, adopting a microservice architecture can be straightforward, but many teams still need to migrate existing monoliths that have become bloated due to traffic growth and feature expansion.

1. Preparation for Microservice Migration

1. Fully understand the business, which is a prerequisite for service decomposition, communication design, and resource integration.

2. Embrace microservice design principles: small releases and rapid iteration.

3. Provide a fast provisioning environment, relying on cloud computing and container technologies for rapid delivery.

4. Reasonable service splitting that aligns with team structures or can influence organizational adjustments, following Conway's law and its inverse.

5. Basic monitoring capabilities, covering both technical and business metrics.

6. Rapid application deployment capability, requiring a deployment pipeline that enables fast releases.

7. DevOps automation: strong CI/CD practices, quick response to incidents, and seamless collaboration among development, testing, and operations.

2. Strategies for Microservice Granularity

We previously covered the "What" and "Why" of microservices; this section explores the "How" of service decomposition.

There is no absolute standard for splitting; granularity must be planned according to business scenarios, and adjustments are needed as the business evolves.

2.1 Business‑Logic‑Based Splitting

Applying the single‑responsibility principle, group closely related functionalities into one service grain. For example, in an office system, attendance, workflow, and video conferencing represent distinct business domains and can serve as starting points for splitting.

2.1.1 Domain Model Splitting

Domain‑Driven Design (DDD) suggests dividing the system based on business domains. In e‑commerce, typical domains include user accounts, product catalog, orders, customers, and logistics, each of which can be isolated as independent service grains.

2.1.2 User‑Group Splitting

When splitting by user groups, ensure that roles have minimal functional coupling and clear domain boundaries. For instance, in an educational system, teacher and student scenarios are largely independent, making them candidates for separate services.

2.2 Splitting for Extensibility

Separate stable, generic services (the "unchanged" part) from frequently changing, business‑specific functionalities (the "changed" part). According to the 80/20 rule, roughly 20% of the system changes often, while the remaining 80% stays stable.

In e‑commerce, modules like user information, basic product data, and logistics are stable, whereas promotional activities (e.g., flash sales) change frequently and should be isolated.

2.3 Reliability‑Based Splitting

2.3.1 Core‑Module Isolation

When splitting MySQL and Redis clusters, critical modules are placed in dedicated high‑performance clusters to prevent failures in less critical modules from affecting them.

Key modules such as account information, authentication, and service registry are isolated into their own service grains to ensure high availability.

2.3.2 Primary‑Secondary Link Splitting

Systems often have primary business flows (core) and secondary flows. The primary chain (e.g., product search → detail → cart → checkout → payment) must receive the best resources and isolation to maintain reliability.

Benefits of this split include fault tolerance with multi‑level degradation, resource allocation favoring high‑frequency primary services, and isolation to prevent secondary service issues from impacting the core.

2.4 Performance‑Driven Splitting

Identify ultra‑high‑concurrency scenarios (e.g., points bidding, flash sales) and isolate them into separate services to meet stringent latency requirements and maintain independence from other workloads.

3. Summary of Splitting Principles

Start small, then expand; begin with coarse granularity, then refine.

Split based on business logic (user groups, domain models).

Split for reliability (core module isolation, primary‑secondary link separation).

Split for performance (isolate high‑throughput scenarios).

Ensure interfaces are idempotent.

Avoid nested data structures; use transparent data passing.

Standardize project structure to follow microservice conventions.

First split services, then adjust databases once service granularity is defined.