Design and Evolution of the Price‑Increase Coupon Service for a C2B Recycling Platform

The C2B recycling business recovers 3C digital products from users, offering quotations, quality checks, and cash payments; to boost order volume, it introduces cash subsidies called “price‑increase coupons” (加价券) for sellers who meet sales thresholds.

Terminology

Coupon configuration : stores the settings of price‑increase coupons.

Coupon relation table : records the binding between coupons and users.

Evolution Process

1.0 Experiment Phase

During early development the coupon data model was undefined and frequently changed; configurations were kept in Apollo Config Center for rapid experimentation, despite lacking strong validation and visual tools.

The relation table was a single MySQL table without sharding, as data volume expectations were unclear.

2.0 Platformization

After the experiment stage, product clarified coupon rules and expanded usage to on‑site, offline, and external collection scenarios, exposing limitations of Apollo.

Problems identified: no validation rules, high JSON‑editing cost, and lack of visual management.

The solution was to retire Apollo and build a dedicated marketing backend.

3.0 Table Splitting

Growth pushed the coupon relation table toward billions of rows; a sharding strategy was needed.

Two approaches were considered: a JDBC proxy (backend‑only) and a database‑level proxy (requires DBA involvement). The team chose the JDBC proxy, using the widely adopted sharding-jdbc framework.

Based on a five‑year growth model, the table was split into 8 databases with 8 tables each, using user UID hash for partitioning.

4.0 Intelligent Construction

Intelligent coupon issuance leverages user behavior (orders, reviews, browsing) to recommend suitable coupons.

Data flow: Kafka captures behavior logs → Flink processes and filters → results sent to a search‑recommend service → the service provides personalized coupons when users access activity pages.

5.0 Elasticsearch Integration

When data volume exceeds database capabilities for complex queries, Elasticsearch is introduced for full‑text and flexible searches.

To avoid OOM from caching all coupon configs locally, Elasticsearch handles coupon retrieval, accepting eventual consistency and sub‑second latency.

ES Cluster Optimization Tips

Compress transferred data; index only required fields and fetch only primary keys.

Route queries by UID to limit search scope.

Archive expired coupons; move MySQL archives to TiDB and purge unnecessary ES data.

Use keyword fields for exact numeric lookups (e.g., category, model).

6.0 NoSQL and Read‑Replica Enhancements

Peak traffic reaches >10k QPS, stressing services and databases.

Read‑write separation to handle read‑heavy scenarios.

Redis caching for frequent interfaces.

Circuit‑breaker fallback when ES or services experience timeouts.

Reflections & Summary

Key takeaways include avoiding over‑design, assigning appropriate people to tasks, sharing technical insights, and adhering to architectural principles such as rollback capability, feature toggles, built‑in monitoring, mature technology adoption, resource isolation, horizontal scalability, and rapid iteration.

Author

Wang Ruigang – Backend developer in the Innovation Technology Department, responsible for the online recycling business.