How Vivo Browser Scaled to Millions: Architecture Upgrade for High‑Performance Coin Incentive System

Business Background

In digital product operations, a virtual coin incentive system drives user engagement and loyalty, especially in content‑heavy apps such as news, short videos, novels, and short dramas. Vivo Browser introduced a coin system in 2021 for its novel channel and expanded it to other scenarios, including the video tab, creating a need to upgrade the legacy architecture to handle massive traffic.

Technical Pain Points

Complex task logic: Growing variety of coin tasks increased code complexity and blurred service boundaries.

Service pressure: Expected DAU growth from millions to tens of millions exceeded the capacity of the existing architecture.

I/O bottleneck: A single‑database design occasionally caused performance degradation.

Coin leakage: Simple reconciliation logic lacked strict data‑consistency checks.

Security vulnerabilities: Incomplete risk‑control measures left the system exposed to abuse.

Architecture Upgrade Goals

Support diverse task patterns via a refined state‑machine model.

Handle high concurrent traffic with a scalable service cluster.

Eliminate I/O pressure by adopting distributed databases.

Ensure high‑precision coin data safety.

Implement strict risk‑control to curb malicious activity.

Additional objectives include dynamic business expansion with low‑coupling modules and a cost‑effective, reusable architecture for future token‑based services.

Upgrade Plan

Service Layer

Traffic is isolated by splitting services for novel, information‑flow, and generic browser functions, routing requests via path‑based domain routing. The coin business is divided into two independent services—Browser Coin and QuYue Coin—each with its own risk‑control and arbitration logic, enabling independent iteration and easy replication.

Data Layer

To break the single‑database bottleneck, the database is refactored with sharding and table partitioning:

Database sharding: Users are hashed to N databases; each database contains M user tables.

Large‑table decomposition: Subscription, lottery, and other auxiliary data are moved to separate tables, leaving only the core coin balance in the main user table.

Balance design: A monthly balance table stores recent coin flow, while older records are archived to a month‑balance table and eventually to Hive for offline backup.

Data Consistency

The new architecture integrates an arbitration system that performs reconciliation, verification, balancing, and compensation to guarantee coin data accuracy. Offline data‑task services provide real‑time notifications and historical queries for failed reconciliations, reducing user complaints.

Soft Transaction

Coin acquisition, withdrawal, and redemption involve cross‑service calls, leading to distributed‑transaction challenges. Soft transactions are employed: single‑database operations handle coin adjustments, while lightweight transactions coordinate across systems, avoiding heavyweight TCC patterns. Each coin claim is bound to an order ID for traceability; failed network calls are compensated offline to ensure eventual consistency.

Conclusion

The welfare‑center upgrade transformed a single‑scenario, simplistic coin system into a high‑availability, replicable architecture capable of supporting tens of millions of DAU. By isolating traffic, sharding data, redesigning balance tables, and adding arbitration and soft‑transaction mechanisms, performance stabilized, storage costs dropped, and data consistency improved, laying a solid foundation for future growth.