Lessons from Three System Architecture Refactorings: Balancing Business Continuity and Technical Improvement

For programmers, the most painful thing is not just changing requirements or debugging, but undertaking a simultaneous business development and architecture refactoring effort that must satisfy both management and peers while ensuring business continuity.

The author describes three distinct refactoring projects undertaken after joining UC, each illustrating different architectural pain points and solutions.

M System : a backend managing game data that suffered from tight coupling between public game data and P‑business‑specific data, leading to poor scalability. The refactor split the data layers, decoupling the systems, resulting in a four‑fold increase in monthly release frequency.

S System : the core game‑access system with a single‑point‑of‑failure primary database. The refactor introduced a dual‑center architecture, enabling any data center to take over full service, boosting availability from three nines to four nines.

X System : an innovative business platform that had accumulated all functionalities into a single monolith, causing poor extensibility and risk of total outage when any component slowed down. The refactor decomposed the monolith into multiple subsystems communicating via interfaces, improving development speed and fault isolation.

The author emphasizes that successful refactoring requires identifying the truly critical problems among many symptoms, focusing resources on high‑impact issues, and avoiding the temptation to “fix everything” which leads to wasted effort and burnout.

Post‑refactor, targeted optimizations could be performed quickly within teams without extensive cross‑team coordination, demonstrating the value of a clean architectural foundation.

Source: 云栖社区 (https://yq.aliyun.com/articles/42321)