Douyin's Video Red Packet System: Architecture, Scaling Challenges & Solutions

Business Background

During the Spring Festival activity, Douyin combined short videos with red packets, allowing users to send blessings to fans and friends by creating a video and attaching a red packet.

Business Play

The activity includes two modes: B2C and C2C. Below is a brief introduction to each flow.

B2C Red Packet

In the B2C flow, users join the Spring Festival red‑packet rain on Douyin or Dou Lite, where they may receive a subsidy. After receiving the subsidy, users can jump to the camera page, record a video, and see a red‑packet pendant showing the allocated subsidy. Selecting the subsidy and submitting the video completes the red‑packet distribution.

Figure 1: Spring Festival red‑packet rain → subsidy → pendant → B2C red‑packet sending tab.

C2C Red Packet

In the C2C flow, users record a video, click the pendant, fill in the amount and quantity, choose the receiving range, and then send the red packet, which triggers the checkout page. After payment, the user proceeds to publish the video, completing the C2C red‑packet distribution.

Figure 2: C2C red‑packet sending tab → payment page → pendant after payment.

Red Packet Claim

Both B2C and C2C red packets share the same claim process. When users see a video with a red‑packet button, they click it, open the red‑packet cover, and claim the amount. A result popup shows the claimed amount and provides a link to the detail page, where users can view others' luck.

Figure 3: Red‑packet video → cover → claim result → detail page.

Problems Encountered

General Red‑Packet System Design

The activity required support for both B2C and C2C red packets, which share common operations (issue and claim) but differ in subsidy handling and settlement. A unified system was needed to manage multiple red‑packet types, query information, and drive state machines.

Large‑Scale Subsidy Distribution

During the event, each red‑packet rain generated massive traffic. Directly writing all requests to the database would exhaust scarce DB resources, so the design had to minimize DB load.

Red‑Packet Claim Scheme Selection

High‑frequency claim operations risk hotspot accounts. Various schemes were evaluated to balance concurrency and performance for video red‑packet scenarios.

Stability and Disaster Recovery

The B2C and C2C pipelines depend on many downstream services. In case of black‑swans, rapid mitigation and impact reduction are essential.

Financial Security Assurance

Over‑issuance of subsidies or duplicate settlements could cause significant losses. Both B2C subsidies and C2C payments require robust safeguards.

Red‑Packet System Stress Testing

Traditional single‑interface load testing is insufficient because issuance, claim, and query are interdependent. Full‑chain testing with realistic data and payment mocks is needed to expose true bottlenecks.

Our Implementation

Core Operations

The system handles three core actions: sending red packets, claiming them, and refunding unclaimed ones. It also supports subsidy issuance for B2C and maintains state machines for all operations.

Modular Division Principles

Functional cohesion: each service handles a single responsibility.

API gateway performs simple proxying only.

Asynchronous task decomposition.

Read‑write separation: core operations and queries are split.

Modules

Red‑Packet Gateway Service : HTTP API gateway for client/H5 integration, routing to downstream RPCs, with rate‑limiting, auth, and degradation.

Red‑Packet Core Service : Implements issuance, claim, refund, subsidy handling, and state‑machine progression.

Red‑Packet Query Service : Provides details, status, and subsidy information.

Red‑Packet Async Service : Processes asynchronous tasks such as transfers, refunds, and subsidy state updates.

Red‑Packet Base Service : Shared utilities for DB, Redis, TCC, constants.

Red‑Packet Reconciliation Service : Daily reconciliation with finance.

Overall Architecture

Large‑Scale Subsidy Distribution Handling

Synchronous Issuance

Initially, subsidies were issued synchronously, causing DB overload during peak traffic.

Asynchronous Issuance

The flow switched to MQ‑based peak‑shaving. Users receive an encrypted token for UI display while the subsidy is processed asynchronously, reducing DB pressure but introducing a ~10‑minute delay before the subsidy appears in the DB.

Final Solution

Before using a subsidy to send a video red packet, the system first writes the subsidy to the DB, ensuring consistency. Query interfaces merge the token list from the reward service with DB records to present a complete view.

Red‑Packet Claim Scheme Selection

Pessimistic Lock

Locking the DB row during claim is simple but leads to lock contention under high concurrency.

Pre‑Split Red Packet

Pre‑splitting a red packet into multiple smaller packets reduces lock granularity. Allocation uses Redis auto‑increment; fallback to DB lookup if Redis fails.

Final Scheme for Video Red Packets

Given the relatively low concurrent claims in video feeds, the simple lock scheme is chosen, supplemented with Redis rate‑limiting, in‑memory locking, and asynchronous transfer to reduce DB pressure.

Redis rate‑limiting based on remaining packet count.

In‑memory lock per packet to shift contention away from DB.

Asynchronous transfer to hide long‑running payment calls.

Stability and Disaster Recovery

Interface Rate Limiting

Rate limits are set after estimating peak issuance and claim volumes, using full‑chain traffic analysis.

Business Degradation

Core service failures trigger graceful degradation with user‑friendly messages; non‑core failures downgrade features (e.g., subsidy display) while keeping core flows functional.

Multi‑Mechanism State‑Machine Advancement

State progression relies on callbacks, periodic MQ polling, and scheduled tasks with alerting for stuck orders.

Financial Security Guarantees

Idempotency

All issuance, claim, and refund APIs enforce idempotency via unique order numbers. Subsidy issuance uses a separate sharding key to avoid cross‑shard duplicate inserts.

Reconciliation

Hourly Hive reconciliation validates B2C subsidy‑to‑claim and C2C payment‑to‑transfer‑to‑refund flows, ensuring monetary consistency.

System Stress Testing

Full‑chain scripts simulate realistic B2C and C2C user behavior, including subsidy issuance, video upload, claim concurrency, and payment interactions, with mock switches for external services.

Figure: B2C stress test flow – subsidy issuance → query → video red‑packet send → concurrent claims.

Figure: C2C stress test flow – payment mock → video send → claim → refund.

Future Plans

Service Set Architecture

To improve fault isolation, each service and its storage will be packaged as an independent set, enabling traffic sharding, horizontal scaling, and rapid failover to backup sets.