How to Build a Perfect Target Architecture for Microservice Migration

00 Introduction

Facing growing business demand and improving infrastructure, our company scheduled a microservice transformation. After two days of intense discussion, we clarified many business boundaries and compiled the lessons learned into this summary.

01 Microservice Transformation Implementation Plan

The migration is a long‑term effort (about two years for similar scale systems). To keep it orderly, we defined a concrete plan:

Provide a company‑wide target architecture blueprint.

Select frameworks and complete infrastructure upgrades.

Establish microservice development standards.

Conduct typical project pilots and summarize experience.

Revise architecture guidelines.

Roll out large‑scale microservice migration.

Following this plan should yield a more rational system structure, lower coupling, clear business boundaries, and a tree‑like dependency hierarchy.

02 Current Architecture Situation

Our third‑party payment platform consists of many independently built subsystems, resulting in a chaotic call graph, duplicated functionality, and resource waste. The main problems are:

Slow new‑product development, unable to keep up with rapid business growth.

Difficulties in achieving operational automation.

Limited ability to scale performance through capacity expansion.

Microservice principles can address these issues by extracting common services, improving infrastructure performance and availability, and using domain‑driven design to define clear service boundaries.

03 Main Discussion Topics

Key debates during the design session included:

Where to draw the boundary between low‑level capabilities and upper‑level products.

When to split services versus when to merge them.

Whether single‑point modules are acceptable in the business layer.

The extent of organizational and responsibility changes required.

We concluded that standardized functions should be provided by underlying services, while highly specialized features belong to the product layer. Splitting services remains desirable for business logic, but common utilities (e.g., unified sequence numbers, session management) should be abstracted into shared services. The microservice approach also influences team structure, encouraging full‑stack, high‑cohesion, low‑coupling teams responsible for the entire product lifecycle.

04 Target Architecture (Blueprint)

Based on the consensus reached, we produced the following target architecture diagram:

This article reflects my personal understanding of microservice migration and business refactoring and does not represent the official company architecture; design decisions always require weighing trade‑offs and timing.