How iQIYI Unified Its Points System with MongoDB 7.0 for Massive Scale

Background

iQIYI’s points system, a core capability for user operations, membership incentives, and cross‑platform interaction, serves four major business lines (Fast‑Version, Baseline, International, and Integrated) with many sub‑lines and multiple independent points accounts per user, resulting in highly diverse data and massive concurrent access.

Current Architecture and Challenges

The platform uses a dual‑storage design: MySQL stores total points for operations such as addition, subtraction, and aggregation, while MongoDB stores detailed transaction logs for historical queries. As user volume and the number of points lines grew, the architecture faced several issues:

MySQL became a performance bottleneck with limited write capacity and complex horizontal scaling.

Separate storage introduced consistency and maintenance complexities, requiring distributed transactions or dual‑write compensation.

Operating and evolving two distinct database systems increased development and ops overhead.

Storage Architecture Selection

The team evaluated storage solutions against five key requirements:

Scalability: Unlimited horizontal expansion.

Concurrency: Support for high‑frequency points adjustments.

Transaction Support: Atomic updates of total and detail data.

Disaster Recovery: High availability with automatic failover across data centers.

Modeling Flexibility: Adaptable schema for diverse business needs.

MongoDB 7.0 was chosen for its native sharding, flexible document model, enhanced multi‑document transactions, and robust monitoring capabilities, making it ideal for high‑concurrency, high‑availability scenarios.

Migration Strategy

The migration was executed in two stages, moving both points details and total values to a MongoDB 7.0 cluster while maintaining service continuity.

Detail Data Migration

Full and incremental data sync from MongoDB 3.4 to MongoDB 7.0 using an enhanced open‑source mongoshake tool.

Tool improvements included a rebuilt logging system with Uber zapLog, operation‑type filtering, optimized incremental sync, latency monitoring, and Prometheus‑compatible metrics.

Read traffic was switched to the new cluster, followed by downstream sync adjustments (e.g., Spark jobs using mongo-spark-connector).

Write traffic was later migrated, and the old MongoDB 3.4 instance was decommissioned.

Total Value Migration

Created point‑line collections in MongoDB 7.0 with appropriate indexes and sharding.

Subscribed to MySQL binlog via a DBIO tool, publishing full data to a messaging system.

Real‑time consumption of messages ensured eventual consistency, with throttling controls and an ext_info field for request replay.

After verification, writes were redirected to MongoDB 7.0 and the legacy MySQL store was retired.

Progress and Benefits

Both the Integrated and Fast‑Version points systems have completed migration. The new architecture delivers:

Enhanced Stability: Reduced timeout errors and more predictable response times.

Higher Concurrency: Sharding enables horizontal scaling, eliminating MySQL lock contention.

Stronger Consistency: Majority write concern and transaction support remove the need for complex distributed‑transaction logic.

Improved Development Efficiency: A single data model simplifies codebases and reduces maintenance effort.

Overall, the migration provides a solid, scalable foundation for iQIYI’s future points‑related services.