Refactoring Practices and Strategies for Large‑Scale Microservice Systems

Author Mega, a Ctrip international ticket engineer focusing on Java and DevOps, shares insights gained from participating in a large‑scale end‑to‑end refactoring project.

Definition : Refactoring is the process of improving a software system’s internal structure without altering its external behavior.

Reasons for refactoring :

Organizational restructuring – microservice architecture demands services with single responsibilities, so changes in team structure often require architectural refactoring.

Improving development efficiency – reducing maintenance effort, freeing resources for higher‑value tasks, and shortening delivery cycles.

Paying back technical debt – legacy shortcuts made for speed increase future workload; refactoring helps eliminate that debt.

Application modernization – converting legacy code to stateless services enables cloud elasticity and cost optimization, and allows CI/CD pipelines to accelerate delivery.

Impact scope : Refactoring can be divided into high‑level architectural refactoring and low‑level code refactoring. Code refactoring changes internal code without affecting external behavior, while architectural refactoring reorganizes the system’s logical layers and often involves multiple teams.

Comparison of architectural vs. code refactoring :

Code refactoring is usually confined to a single team, low risk, and easy to verify.

Architectural refactoring requires consensus across several teams or a technical committee, carries higher risk and cost, and demands senior engineers familiar with the entire service chain.

Refactoring plan : Before coding, conduct deep analysis of the existing system, prioritize components, and define phased milestones. Plans must be flexible to accommodate new business requirements that emerge during the refactoring process.

Team communication : Coordinate closely with business‑facing development teams, prioritize refactoring of new‑feature areas, and avoid a situation where freshly delivered features immediately become refactoring tasks.

Layered design : Define clear boundaries between services and modules, apply the single‑responsibility principle, and separate concerns so that each class serves one purpose, improving testability, reusability, and maintainability.

Gray‑release strategy : Introduce an abstraction layer (e.g., interface‑driven design) that supports both old and new implementations. Use feature toggles to switch between versions transparently, enabling gradual rollout, quick rollback, and reduced cognitive load for developers.

Quality improvement :

Static analysis – tools like Sonar to detect circular dependencies, cyclomatic complexity, excessive methods per class, long methods, and unused code.

Automated testing – prioritize integration tests to verify behavior before and after refactoring; use mocks to isolate external dependencies and ensure stable test data.

Link comparison – after each milestone, run end‑to‑end automated tests that compare results of the refactored version with the production version, using tools such as SmartDiff to record differences in Elasticsearch for analysis.

Observability : Define non‑functional metrics (e.g., P90 latency < 100 ms) and visualize them continuously to verify that the system still meets original architectural goals after multiple iterations, helping teams regain confidence in the architecture.

Recommended reading :

10 Effective Ways to Reduce Client‑Side Timeouts at Ctrip

Performance Optimization of Ctrip’s Transit Routing Solution

Low‑Cost, Low‑Error Serverless Delay Queue Based on Kafka at Ctrip

Accelerating Android Build with Ctrip’s AAR Compilation Optimization