Xianyu Coin Service Migration: A Service‑Based Data Migration Approach

Background Alibaba’s “big middle platform, small front‑end” architecture makes front‑line services agile. Xianyu, as a small front‑end, relies on the Alibaba points middle‑platform for its virtual currency (Xianyu Coin). The legacy points platform “KingTower” is being retired and merged into the new “Banliang” points platform, requiring migration of data and service dependencies.

Current Situation Xianyu Coin has over 100 million users, with daily new users in the ten‑thousands and billions of operations.

Migration Plan Overview The migration consists of four phases: preparation, data migration, dual‑write, and service switch.

Preparation 1. Platform capability alignment : Ensure the new platform provides all capabilities of the old one, or supplement missing features at the business layer. 2. Interface alignment : Compare old and new service APIs, map parameters, and identify gaps that need to be filled. 3. Business interface refactoring : Adapt business code to handle the new API signatures, preserve existing logic (e.g., sign‑in bonus), and guarantee compatibility.

Data Migration Two modes are used: • Active migration : Triggered by a user’s point operation. The flow reads a migration flag, acquires a global Redis lock, reads the old points, writes them to the new service, sets the migration flag, and releases the lock. • Passive migration : Triggered by the system. A batch job computes the list of users to migrate, distributes the work across machines, and follows the same read‑lock‑write‑flag‑release sequence.

Active migration suits active or newly created users, while passive migration handles the massive existing user base. Both require careful handling of concurrency (global distributed lock) and transactional integrity (any step failure aborts the migration for that user, triggering a retry).

Dual‑Write After a user’s data is migrated, the system writes to both old and new point services. The old service emits an asynchronous success message containing an idempotency key; the new service processes this message only if the operation has not been performed yet, ensuring eventual consistency.

Reconciliation Service A scheduled task periodically compares point balances between the old and new platforms for migrated users. Temporary inconsistencies due to read order are resolved by retrying until eventual consistency is achieved.

Service Switch Once migration, dual‑write, and reconciliation are stable, the old service is decommissioned. The switch is performed gradually: first a whitelist, then user‑ID modulo 1000 rollout, with read‑gray and write‑gray phases to allow rollback if issues arise.

Conclusion The migration from KingTower to Banliang was completed in about one month without user impact. Service‑based migration offers advantages over direct database migration: no need to know underlying storage, better controllability, and built‑in rollback. Drawbacks include longer migration time due to service QPS limits and the need to handle RPC failures.