System Refactoring: Philosophy (Dao) and Techniques (Shu)

Recently I have been involved in many refactoring projects, such as Gateway, AMAPS, and shared‑service decomposition, aiming to improve server resource utilization, architectural rationality, and development efficiency. This article summarizes the key points and common pitfalls of system refactoring, offering practical guidance rather than repeating generic solutions found online.

What are “Dao” and “Shu”? In my view, Dao is the philosophy or mindset, while Shu refers to the concrete methods. Effective refactoring requires both.

1. The Dao of System Refactoring

Before starting a refactor, ask: Is it the right time? What preparations are needed? How can we ensure the work meets its goals? Refactoring should always solve a real problem—performance, security, or faster CI/CD—not be done for its own sake. Unnecessary refactoring adds risk without business benefit.

Set clear, measurable goals following the SMART principle. For performance‑oriented refactors, specify metrics such as response‑time reduction, QPS increase, or resource savings. For less quantifiable goals like high availability, define concrete events (e.g., zero‑impact during a data‑center outage) as success criteria.

Design must be balanced: avoid under‑design (lack of abstraction) and over‑design (excessive extensibility that adds complexity). Consider cost‑benefit when introducing new designs.

Adopt an incremental, “small‑step‑fast‑walk” approach. Break the refactor into phases, similar to scaffolding in construction, to keep risk manageable. Example: an order service was split into four modules (order creation, CP sync, processing, statistics) to enable staged rollout and validation.

2. The Shu of System Refactoring

Service‑orientation

Service‑oriented design embodies abstraction, decoupling, divide‑and‑conquer, and unification. Its goals include rapid iteration, code decoupling, independent deployment, scalable expansion, and graceful degradation. Poor service design can increase complexity, so clear objectives are essential.

Key considerations:

Emphasize weak coupling between services; communication mechanisms are secondary early on.

Choose appropriate service granularity—start with larger grains if unsure, then refine.

Design for high fault tolerance: analyze dependencies, distinguish strong/weak ties, and implement fallback mechanisms.

Cache Design

Caching is a common performance technique but not a silver bullet. Avoid defaulting to cache for every performance issue. Consider cache avalanche and penetration risks, implement degradation strategies, ensure high availability, and design expiration policies (e.g., staggered TTLs).

Internal Optimizations

Code refactoring: restructure code and eliminate bad smells; requires solid domain‑driven design knowledge.

Asynchronous transformation: effective for I/O‑bound workloads but demands a complete technical solution and team expertise in reactive programming.

Sharding (database/table splitting): apply when data volume exceeds single‑node capacity. Use appropriate primary‑key strategies (e.g., Snowflake, TDDL). For cross‑shard queries, prefer ES for moderate data and ES+HBase for massive datasets.

3. System Evaluation

From an R&D perspective, evaluate systems across six dimensions: performance, high availability, scalability, elasticity, security, and operability. Use a three‑level rating (severe lack, insufficient, satisfied) for each dimension, considering the specific business context. Remember that improvements in one dimension may affect others.

In summary, successful system refactoring is a systemic engineering effort. The biggest challenge lies in comprehensively weighing multiple factors and selecting the most optimal solution.