Large-Scale Refactoring of a Video Streaming Service: Architecture Redesign and Implementation

With the rapid growth of video streaming business, the legacy engineering faces increasing complexity in architecture design, code quality, and engineering capability. To address these issues, a large‑scale refactoring project was launched.

The article is divided into two parts: a theoretical overview and a practical guide.

Problem Definition : The new architecture must solve coupling, poor code quality, massive classes (e.g., a 3000‑line entry class), weak engineering tooling, lack of documentation, and insufficient monitoring.

Team Context : The team is growing, spans multiple business lines, and needs a simple, low‑cost solution that does not increase learning overhead.

Cost of Adoption : Migration should be incremental—first move large code blocks to a new project, then fully transition.

Core Goal : “Architecture decoupling & fast iteration”.

Implementation Strategy : Adopt a vertical layering (business, framework, foundation) combined with horizontal modularization (micro‑services). Each module becomes an independent service registered in a service registry and accessed via the video‑stream context.

The new architecture consists of only seven core classes (~800 lines) that support tens of thousands of business lines.

Pre‑Refactor Preparations :

Enforce code style and static analysis (Android Lint, SonarLint + SonarQube).

Build engineering scripts to automate repetitive tasks.

Introduce automated testing (functional, stability, performance, unit tests).

Safe Refactoring Practices :

Perform small, incremental steps (extract method, move class, etc.).

Run tests after each step.

Use IDE’s safe‑refactor features (extract, inline, encapsulate, rename, move, remove unused code, pull‑up/pull‑down members, replace inheritance with delegation).

Architecture Guard : Use ArchUnit to enforce package, class, layer, and dependency rules, preventing accidental regressions.

Gray Release :

Set up data collection (metrics, error codes, performance, business KPIs).

Monitor stability (crash, ANR) before 10% rollout, then monitor performance and user feedback after.

Apply A/B testing with two experiment buckets and two control buckets.

Results : Over 400 commits and tens of thousands of changed lines. Post‑refactor improvements were observed in architecture design, code quality, and engineering efficiency.

The article concludes with a brief team introduction and references to related tooling and best‑practice resources.