Scaling a C2B Recycling Coupon System: From Config Center to Sharding & Elasticsearch

Business Overview

In the C2B recycling business, users request a valuation for electronic devices, ship them to the platform, receive a quality inspection and a final quote, and upon acceptance the platform pays the user.

Terminology

Rights configuration : stores the coupon configuration data.

Coupon relation table : stores the binding relationship between coupons and users.

Evolution Process

1.0 Experiment Phase

During the early stage the coupon data model was undefined and changed frequently. Configuration was kept in Apollo Config Center for rapid iteration, but it lacked strong validation, incurred high configuration cost and was error‑prone. The coupon‑user relation was stored in a single table without sharding.

2.0 Platformization

After the experiment phase the product clarified the coupon model and expanded its use to on‑site, offline and external recycling channels. Apollo’s drawbacks became evident, so a dedicated marketing backend replaced the config center, providing visual tools and reducing operational cost.

3.0 Table Splitting

When the number of user‑coupon bindings approached billions, a sharding strategy was required. Two options were considered:

JDBC proxy (sharding‑jdbc) – backend‑only implementation.

Database proxy – requires DBA involvement.

The team chose the JDBC proxy using the widely adopted sharding-jdbc framework. Based on growth modeling, the single table was split into 8 databases each with 8 tables, using a hash of the user UID for routing.

4.0 Intelligent Coupon Recommendation

Coupons are now recommended based on user behaviors (orders, reviews, browsing). The workflow:

Kafka streams collect user behavior logs.

Flink consumes the Kafka messages, filters rules, and forwards relevant data to the search‑recommendation service.

When a user visits an activity page, the recommendation service returns the most suitable coupons.

Coupon configuration is cached locally; updates are broadcast via MQ and a periodic fallback task ensures consistency. Filtering is performed in memory using configuration IDs, then the matching coupons are fetched from the database.

5.0 Elasticsearch Middleware

When data volume grew, relational databases could no longer handle complex full‑text or flexible queries efficiently. Elasticsearch was introduced to provide fast search with eventual consistency and second‑level latency, which is acceptable for coupon retrieval. Optimizations include:

Compressing transferred data and indexing only required fields.

Routing queries by user UID to limit the search scope.

Archiving expired coupons to keep index size manageable.

Using keyword fields for exact matches (e.g., category, model).

6.0 Stability Enhancements (NoSQL, Read‑Write Separation, etc.)

Peak traffic can exceed 10k QPS, stressing the service and database. Stability measures applied:

Read‑write splitting to isolate writes and tolerate replica lag.

Redis cache overlay for hot interfaces.

Circuit‑breaker with fallback strategies for Elasticsearch or service timeouts.

NoSQL storage for high‑volume coupon data.

Design Principles & Takeaways

Avoid over‑design; keep solutions simple.

Assign the right people to the right tasks.

Share technical insights within the team for faster problem solving.

Key architectural principles: rollback capability, feature toggles, built‑in monitoring, use mature technologies, resource isolation, horizontal scalability, and rapid iteration.