How to Refactor a Decade‑Old Monolith into a Microservices Architecture

1. When to Refactor an Old System

Refactoring old systems brings mixed feelings: developers enjoy tackling legacy code, while business teams worry about potential delays in new feature delivery. Deciding to refactor should consider technical necessity, cost‑benefit analysis, leadership support, business seasonality, and team readiness with new frameworks.

2. Current State of the System

The target for refactoring is a monolithic application built over ten years ago, characterized by:

Single‑tenant architecture with over 200 tables, many holding tens of millions of rows, some exceeding a hundred million.

Mixed required and unnecessary business functions accumulated during rapid early‑stage development.

Complex interconnections with numerous external systems.

3. Desired Goals

Maintain normal business operation.

Ensure other systems can continue calling the service without disruption.

Upgrade the technical architecture from a monolith to a microservices architecture.

Because microservices require database splitting, the migration involves moving tables to new databases across data centers.

4. Refactoring Approach

4.1 Preserve Business Continuity

Develop the new system in parallel, keep the old system and database running, and switch traffic to the new domain once deployment is complete.

4.2 Preserve External System Calls

Two strategies are used:

Keep existing interfaces unchanged so the new system remains compatible (e.g., HTTP, Hessian, RMI).

If external systems are willing to upgrade, adopt new interfaces for better integration.

4.3 Upgrade Architecture to Microservices

Data Migration and Upgrade

Given the cross‑data‑center scenario and large data volume (hundreds of GB), a two‑phase migration is performed: bulk data (snapshot) and incremental data. The pipeline uses Zookeeper, Kafka, Canal, and Otter to ensure zero‑downtime migration.

Key steps:

Dump tables to reduce network bandwidth and record dump positions for incremental sync.

Use a temporary backup database on the same server as the new database for large‑table transformations without affecting production.

After bulk migration, synchronize changes from the old database to the new one using Otter for simple mappings and Canal + Kafka + custom consumers for complex business logic.

Once data consistency is verified, switch the application to the new database via a configuration center, ensuring no double‑write occurs.

System and Code Upgrade

The microservices are split vertically by business function and horizontally for cross‑cutting concerns, avoiding overly fine granularity at the start. Spring Cloud is used as the foundation.

Functional analysis is performed from two perspectives:

Internal analysis : code inspection, table and business logic mapping, job scheduling, middleware usage (MQ, Redis), and third‑party integrations.

External analysis : access‑log tracing, database access source analysis, and API call tracking.

5. Reflections

Refactoring an old system is like changing a tire on a highway: preparation and clear boundaries are essential. Recommendations include defining the refactor scope, securing leadership support, thorough analysis of internal and external dependencies, and careful planning of data migration steps.

In summary, start with a well‑defined plan, keep business uninterrupted, and adopt incremental migration techniques to successfully transition from a monolith to microservices.