Design and Implementation of a High‑Availability Red Envelope (Coupon) System

Red envelopes (coupons) are widely used in e‑commerce, ride‑hailing, and other services; to support diverse usage scenarios a robust backend system is required. The article begins by defining the core data model, where a red‑envelope batch is the atomic unit linked to each user’s claim.

The batch model includes two groups of attributes: claim attributes (batch ID, claim ID, claim time window, per‑user limit, total quantity, platform restrictions, ad copy) and usage attributes (validity period, amount (fixed or random), usage platform, type). These attributes enable flexible configuration of redemption rules.

Redemption rules follow a "configuration‑first" principle, allowing definition of scope, stacking/exclusion, cost bearer, deduction method, and usage nodes. Example rule records illustrate how mutual exclusion between batches or merchants is stored (e.g., ref_id="1234",ref_type=1,use_type=2 ).

Another essential component is the red‑envelope code, a unique identifier for each issued coupon. The system must handle both internally generated codes and external partner codes, tracking status and issuance time, and can extend attributes via custom tags.

The claim relationship model captures three aspects: binding a user identifier (user ID, phone, WeChat OpenID) to a batch, code, and status; providing direct query/display without joins; and supporting multi‑dimensional statistics such as claim and usage counts.

1. Red‑envelope generation addresses timeliness, resource efficiency, quantity accuracy, and high‑concurrency safety. Generation can be full or incremental; large batches generate codes incrementally and store them in a Redis list . A background worker replenishes the list when it falls below a threshold, using distributed locks to avoid duplicate inserts.

2. Red‑envelope distribution unifies active and passive triggers: a user request pops a code from the Redis list, records the claim in the database, and pushes a message to MQ for asynchronous processing. Anti‑fraud measures include signatures, SMS verification, black/white lists, rate limiting, and behavior analysis.

3. Red‑envelope verification is performed by external systems (order, merchant, third‑party). The article adopts an eventual‑consistency approach: after a successful external call, a confirmation message is sent to a verification MQ; if no confirmation arrives within a timeout, a worker actively queries the external system.

4. Red‑envelope query is the most performance‑critical part. Four query patterns are identified (frontend/backend, fixed/diverse conditions, hot/cold data, recent/historical). Solutions combine cache (Redis) for hot data, database indexes, read‑write splitting, and search engines (Solr/Elasticsearch) accessed via Nginx+Lua for flexible queries, achieving up to 6 万 QPS in tests.

5. Product tagging for red‑envelopes ensures that items with available coupons display an icon. Three implementation options are discussed: data sync to the product system, direct API calls from the product page, or embedding a custom tag in the product record with proper permission control. The chosen approach uses a distributed delay queue (Redis sorted set or MQ) to manage tag activation and removal accurately.

The final architecture integrates logging, tracing, degradation handling, and API documentation, leveraging MQ and Redis to reduce development cost. The article concludes that red‑envelopes remain a powerful marketing tool, and future work will focus on intelligent, AI‑driven enhancements.