IM Scenarios: A Generic Red Packet Technical Solution

Preface

Red packets are a relatively high-frequency and highly playful scenario in IM. They play a unique role in boosting app user stickiness and retention. Although red packet designs can vary widely across different IM products, the core principles remain the same. This article introduces a relatively generic red packet technical solution. Readers can build on top of this foundation and combine it with their own business and scenarios to add more creative variations.

Role Definitions

A red packet is a comprehensive business scenario that is based on IM and extends to multiple business systems. Let's pre-define the business roles that may be involved.

• IM Server / SDK: Responsible for sending and receiving red-packet messages, as well as delivering various red-packet-related signaling and state-change notifications;
• App Server: The core business server, used for authentication of users sending and receiving red packets;
• Red-packet Server: Handles the core business logic of red packets, such as controlling red-packet send/receive, amount calculation, claim status changes and queries, claim progress, timeout refunds, etc. Generally, it can be merged into the App Server; from here on, we refer to it collectively as the App Server.
• Financial Account Server: Generally refers to a third-party service with fund management, payment, and receipt capabilities — for example, Alipay, WeChat Pay, or a qualified third-party financial vendor — that interacts via APIs. It could also be a self-developed virtual financial system tailored to your scenario.

Core Business Flow

1. Sending a red packet, generally handled by the App Server. The main logic involves:
2. Note: The App Server must calculate the number of shares and the amount per share before sending the red packet, to avoid bad debts.
3. The user enters the red-packet amount and the number of shares.
4. The server validates the user's permissions and account balance.
5. Define the red-packet type and gameplay — e.g. equal-split red packet, lucky-draw red packet, etc.
6. Communicate with the financial account server to deduct the funds.

Sending the red packet: Define a custom message type for red packets, and send it through the IM Server's message-send interface. This includes point-to-point red packets via the single-chat interface, and 1-to-N red packets via the group-chat interface.

Receiving the red packet: The terminal device receives the red-packet message through the IM SDK, and renders the red-packet message in the UI.

Grabbing the red packet: Here we use the more playful group-chat red-packet scenario as an example. When a red-packet message is received, the red packet is in an unclaimed state:

1. To improve user experience and playfulness, different status messages can be sent to the red-packet sender and the grabbers. For example: the sender cares about the claim records of the red packet, which can be implemented using the IM SDK's directed-to-member group messages; the grabbers care about whether the red packet has been claimed, which can be broadcast through the group message interface as a state change.
2. Click "grab red packet", call the App Server's API to randomly and exclusively claim one share. Centralize control of the claim logic and ensure interface idempotency to avoid different people grabbing the same share or the same person grabbing multiple shares. Consider using distributed locks or other relatively generic solutions.
3. For the grabbed share, call the financial account server's API to credit the funds.
4. Call the IM Server's message-send interface to send a red-packet state-change message, updating the remaining shares, claim records, whether the red packet is fully claimed, and other states.

Crediting / Refunding / Withdrawing: This requires the App Server to interact with the financial server's APIs, handling crediting and debiting logic, and processing refunds for red packets that have expired without being fully claimed.

A Typical Interaction Sequence

Other Notes

• Service stability: Group red packets, in particular, are a typical hot-spot scenario. When a group has many members, the claim API will experience very high QPS in a short time. Be sure to apply rate limiting, idempotency, degradation, and caching to avoid being overwhelmed.
• Funds safety: For fund account crediting/debiting, refund, and other operations, ensure interface idempotency to avoid duplicate fund operations. Keep detailed operation logs so that any accidents can be properly traced.
• Red-packet claim algorithm: This is the most playful part of red packets, and can be designed according to your business characteristics. The "double-average" method, the pre-generation method, etc. are common claim algorithms.
• Business security: Sending red-packet messages and handling red-packet claim logic must go through the App Server's APIs. Do not perform calculations directly on the client, to prevent malicious users from bypassing server-side authentication and validation.

---