Inside WeChat Red Packets: User Motives, UI Flow, and Backend Architecture

1. User Analysis

1.1 Why do users send red packets?

For fun and personal enjoyment – sending tiny amounts just to watch the scramble.

To become the focus of a group and gain social visibility.

To promote products or ads subtly by attaching a red packet.

Purely as a blessing or traditional gesture.

1.2 Why do users grab red packets?

Entertainment and the thrill of competition.

Innate greed – even a legal, harmless grab satisfies a primal desire.

To show off speed or luck ("best luck").

To reduce personal loss after sending a packet.

1.3 Why do users share/red‑packet screenshots?

Showcasing wealth ("show‑off").

Comparing results with friends.

2. Entry Points

2.1 Wallet

The wallet is the natural entry because users first receive money there; it aggregates all money‑related features (credit‑card repayment, mobile top‑up, wealth‑management, etc.) and guides users to bind a card before sending a packet.

2.2 Chat Window

In chat, the red‑packet button appears alongside the "+" image‑send button, highlighted during holidays to increase conversion. The UI differs between single‑chat and group‑chat.

3. Interface

3.1 Send‑Packet Page

In a one‑to‑one chat, users input amount and a blessing, then confirm. If a bank card is bound, a password dialog appears; otherwise the app redirects to the wallet payment page.

The UI preserves entered data when switching between "group luck" and "fixed" packets, automatically recalculating per‑person amounts.

3.2 Grab Page

Chat messages display a red‑packet bubble; tapping opens the grab screen.

3.3 Open Page

After tapping "Open", an animation plays and the app navigates to the result page. Android now uses a native UI instead of an HTML page to reduce server load and improve latency.

3.4 Result Page

Shows a list of recipients, highlights the "best luck" user, displays the sender’s nickname, the amount received, and provides shortcuts to the wallet, share, and record pages.

3.5 Shake‑to‑Grab

Shake‑to‑grab packets use the accelerometer; the logic is similar to group‑luck packets but with a minimum amount of ¥2. The UI shows a waiting page when server pressure is high.

4. Backend

4.1 Database Tables (simplified)

user_info(userID, redPacketID, blessing, type, count, amount, timeout)

user_wallet(userID, balance, bankCardID, …)

red_send(redPacketID, senderID, count, amount, blessing, bestLuck, sendTime)

red_receive(redPacketID, receiverID, receiveTime, amount)

4.2 Random Distribution Algorithm

The system generates a pseudo‑random sequence in memory using the packet ID as a seed, avoiding heavy DB reads. Example (Python‑style):

>> red_ID = 1775509988475009
>>> random.seed(red_ID)
>>> min = 1.00
>>> if packet_is_group_luck:
...     min = 0.01
>>> else:  # shake packet
...     min = 2.00
>>> max = (remain_money / remain_num) * 2
>>> amount = random.uniform(min, max)

Two practical schemes are described: a probability‑weighted range (e.g., ¥2‑5 with 85% chance) and a simple proportional formula for shake packets.

4.3 Packet Lifecycle

Sender creates a DB record, stores it in a KV cache, and triggers a long‑connection notification.

Grab operation first decrements the count atomically in cache; if zero, the client sees "already taken".

Open operation reads the cached amount, returns it, and asynchronously writes the result to the DB.

Result page reads the latest list from the DB for display.

Cache uses CAS (compare‑and‑swap) to handle high concurrency; the backend can sustain up to 80 k writes per second with sharding.

5. Interaction Sequence

5.1 Front‑end / Back‑end Flow

Bind bank card (if needed).

Send packet: deduct money, write packet to DB and cache, return packet ID.

Notify other users via long‑connection.

Recipient taps packet → cache checks remaining count.

If available, decrement count and show "Open" button.

On "Open", fetch random amount from cache, display it, and write to DB asynchronously.

Result page updates from DB.

Both group‑luck and fixed packets follow the same split‑grab/open pattern, with minor UI differences.

Additional UI flow diagrams for result pages and shake‑to‑grab are included in the original article.

Author: Jinkey