How Vivo Scaled Its Coupon System: Architecture, Sharding, and Zero‑Downtime Migration

This article details the evolution of Vivo's e‑commerce coupon platform, covering its business drivers, architectural redesign, sharding strategy, multi‑mode issuance, high‑performance safeguards, and a step‑by‑step zero‑downtime migration to a standalone service.

dbaplus Community
dbaplus Community
dbaplus Community
How Vivo Scaled Its Coupon System: Architecture, Sharding, and Zero‑Downtime Migration

Business Background

Coupons are a common e‑commerce marketing tool, serving both promotional and traffic‑driving purposes. The coupon system has been a core module of the Vivo Mall since 2015, initially embedded in a monolithic application and later split into an independent service covering creation, issuance, usage, and statistics.

System Architecture and Evolution

As the mall grew, the monolithic coupling caused bottlenecks: single‑table storage limits, high coupling affecting overall API performance, version‑driven iteration constraints, and lack of reusable coupon capabilities across product categories.

In 2019 the coupon system was decoupled into an independent service with a new architecture (see image). The migration adopted a non‑stop (online) approach to avoid service interruption.

Zero‑Downtime Migration Plan

Stop all coupon‑related back‑office operations to freeze static data.

Classify data: static (backend‑generated, unrelated to users) and dynamic (user‑related, e.g., user‑coupon links).

Switch the current database write mode to single‑write, directing writes to the old mall database.

Deploy the new coupon service and migrate static data via scripts, then verify accuracy.

Enable dual‑write mode so new writes go to both the old mall database and the new coupon database.

Migrate dynamic data, verify correctness, then switch the data source to the new database.

Disable dual‑write, completing the migration.

After migration the request topology changes as illustrated (see image).

System Design

1. Sharding Strategy

To handle massive coupon issuance, the system adopts database sharding based on user ID. Assuming N databases and M tables per database:

Database suffix: databaseSuffix = hash(userId) / M % N Table suffix: tableSuffix = hash(userId) % M All coupons of a user reside in the same shard, enabling efficient aggregation and query.

2. Coupon Issuance Design

The system supports three issuance modes:

Unified claim interface : real‑time user‑initiated claims with strict validation, distributed lock via Redis to prevent over‑claim, inventory deduction, batch insertion, and idempotency using unique DB indexes.

Directed issuance : back‑office bulk issuance for specific user groups, optimized by removing transactions, lightweight validation, batch inserts, and configurable parameters (batch size, read limits, message payload size).

Coupon code redemption : external marketing coupons redeemed via codes, with rules to ensure code uniqueness and prevent replay attacks.

Key techniques include:

Distributed lock keys per coupon to guarantee single‑claim under high concurrency.

Batch operations to reduce DB I/O when claiming multiple coupons.

Idempotent handling via unique constraints on claim tables.

3. Fine‑Grained Marketing Capability

Coupons can be targeted using tag combinations (real‑time or near‑real‑time). This enables per‑user personalization (千人千面) while respecting user consent for sensitive tags.

4. Coupon‑Product Relationship

Two association models are provided:

Blacklist : usable products = all products – blacklisted items.

Whitelist : usable products = explicitly listed items.

A super‑blacklist applies globally across all coupons. Future plans include category‑level associations.

5. High‑Performance Guarantees

Multi‑level caching : local and remote caches reduce DB pressure and handle hotspot keys during traffic spikes.

Read‑write splitting : writes go to the primary, reads are served from replicas with sub‑millisecond replication lag, invisible to users.

External‑service circuit breaking : isolation of third‑party dependencies prevents cascading failures.

User‑dimension coupon field redundancy : frequently accessed coupon rule fields are duplicated in the user‑coupon table to minimize join overhead.

Summary and Outlook

The non‑stop migration succeeded; the independent coupon service has run stably for two years, supporting Vivo Mall’s projected growth for the next 3‑5 years. Decoupling improved iteration speed, and the system now offers a complete, reusable coupon capability. Future work aims to open the platform to other internal businesses as a unified coupon service.

shardingDistributed LockHigh PerformanceCoupon Systemzero‑downtime migration
dbaplus Community
Written by

dbaplus Community

Enterprise-level professional community for Database, BigData, and AIOps. Daily original articles, weekly online tech talks, monthly offline salons, and quarterly XCOPS&DAMS conferences—delivered by industry experts.

0 followers
Reader feedback

How this landed with the community

Sign in to like

Rate this article

Was this worth your time?

Sign in to rate
Discussion

0 Comments

Thoughtful readers leave field notes, pushback, and hard-won operational detail here.