How We Re‑engineered a Massive Video Streaming Platform for Faster Iterations

1. Introduction

As video streaming business grew, its complexity increased, exposing problems in architecture design, code quality, and engineering capability of the legacy system. This article summarizes a large‑scale refactor that redesigns the architecture and improves overall engineering practices.

2. Defining the Problems to Solve

Before designing a new architecture, the team needed a deep understanding of the business and its technical constraints by:

Finding people : communicating with stakeholders (technical, product, design, testing) to clarify requirements.

Reading documentation : reviewing requirement, design, test case, and UI mockups.

Reading code : tracing from UI layers down to business logic.

The key issues identified were:

Architecture problems : high coupling, massive classes (e.g., >1000 lines per class, a video entry class with 3000 lines), poor reusability.

Team status : growing team size, multiple business lines, limited capacity, need for a simple architecture to avoid increasing learning cost.

Implementation cost : large codebase, need to migrate in stages rather than a big‑bang rewrite.

The core goal became architecture decoupling & fast iteration .

3. Designing the Architecture Implementation

The solution combines vertical layering (business layer, framework layer, foundation layer) with horizontal modularization (micro‑services). Each module is a service; services are registered in a service registry and accessed via a video‑stream context. This reduces coupling between business and framework code.

4. Preparation Before Refactoring

Code standards & static analysis : enforce guidelines with Android Lint, SonarLint + SonarQube.

Engineering tools : scripts that condense repetitive tasks into single commands.

Automated testing : functional, stability, performance, and unit tests to catch regressions early.

5. Starting the Refactor

Adopt a small‑step, safe‑refactor approach:

Small steps : extract methods, move code, commit each step for easy rollback.

Frequent testing : run automated tests after each change.

IDE safe‑refactor features : use built‑in refactoring tools to reduce manual errors.

Common refactoring techniques include:

Extract : method, variable, class, super‑class.

Inline : method, variable, class.

Encapsulate : variable, collection.

Rename : signature, variable.

Move : function, field, pull members up/down.

Remove unused code .

Replace inheritance with delegation to avoid tight coupling.

6. Guarding the New Architecture

Use ArchUnit , a free Java library, to write unit‑style tests that enforce architectural rules such as package dependencies, class dependencies, annotation usage, layer constraints, and cyclic dependencies.

7. Gray‑Scale Rollout

Before full rollout, collect data points (efficiency, version, error codes, performance, stability, sentiment) and monitor them. Use an A/B testing pattern (two experiment buckets vs. two control buckets) to compare metrics and address issues early.

8. Impact of the New Architecture

The refactor resulted in over 400 commits and tens of thousands of lines changed, but the core architecture consists of only 7 classes (~800 lines) that support the rest of the codebase. Improvements were observed in architecture design, code quality, and overall engineering capability.

Conclusion

The author invites readers to share their own refactoring experiences and lessons learned.