How Xianyu Built the ‘Resale Lottery’ and ‘Money Tree’ Marketing Engines
This article examines Xianyu's two promotional features—Resale Lottery and Money Tree—detailing their gameplay, underlying business models, and the backend technical solutions such as event collection, idempotent reward accounting, concurrency control, fatigue management, and distributed locking.
Background
Marketing mechanisms are crucial for e‑commerce platforms to drive product promotion and user growth. After introducing the Doraemon (多啦A梦) activity platform, this article explores two specific features built on that system: the Resale Lottery for sellers and the Money Tree for users.
Resale Lottery
Gameplay Overview
When a user publishes an item, they receive a lottery chance (up to 50 per day, cumulative during the campaign). Each lottery draw consumes one chance and may award an Alipay cash red packet or a Double‑11 store coupon. Users can publish items via the Xianyu app or the Taobao Xianyu mini‑program, triggering a POP notification that redirects them to the activity landing page.
Technical Solution
The feature is modeled as two linked activities: (1) publishing to obtain a lottery chance and (2) consuming the chance for a probabilistic draw. Both share a common workflow: pre‑condition → draw → reward. The implementation leverages the Doraemon activity platform and OMEGA event‑collection capability to detect publishing events without invasive code changes. Lottery chances are tracked using a points system with strict idempotency checks and a per‑user global lock to enforce the 50‑chance daily limit.
Key Technical Points
Fairness control: Early in the campaign, cash red packets were scheduled to become active on the hour, causing spikes at whole‑hour timestamps. To prevent users from exploiting this pattern, the system now randomizes multiple activation times within each hour.
Fatigue management: The number of draws per user per time window is limited using Tair’s atomic increment feature. A recommended enhancement is a user‑level aggregate fatigue counter that acts as a safety net when business‑specific limits fail.
Money Tree
Gameplay Overview
After the Double‑11 shopping frenzy, Xianyu offers the Money Tree activity to re‑engage users. Each user can claim a tree that grants a random initial cash amount. By sharing the tree via QR code, link, or WeChat, friends can “shake” the tree; successful shakes reward both parties with cash. Limits include a maximum of four successful invites per user per day and one assistance per day for each helper.
Technical Solution
The activity is abstracted into three sub‑processes: (1) claiming one’s own tree, (2) helping a friend’s tree, and (3) inviting friends to shake one’s tree. All map to a relationship‑system → reward‑claim → reward‑grant model. Relationship data is stored in a Lindorm (HBase‑compatible) table, enabling efficient bidirectional queries. The design favors Lindorm over MySQL to avoid the overhead of maintaining transactional consistency across two tables.
Two primary engineering concerns are addressed:
Loss prevention: Real‑time reconciliation and strict claim limits ensure that each user can only claim one tree, assist once per day, and invite up to four friends, protecting against excessive financial loss.
Concurrency control: Distributed locks (implemented via Tair cache) prevent race conditions when multiple friends attempt to assist the same user or when a user exceeds invitation limits.
Key Technical Points
Idempotency: Achieved through Tair‑based distributed locks, ensuring that each reward operation is executed exactly once.
Reconciliation verification: After a reward is granted, a message‑driven verification step checks the user’s eligibility, providing real‑time accounting of payouts.
Conclusion and Outlook
The article presented the design and implementation details of the Resale Lottery and Money Tree activities, highlighting critical technical considerations such as event‑driven detection, idempotent reward accounting, fatigue control, fairness scheduling, and distributed locking. Existing Doraemon components (fatigue checks, concurrency control, audience validation) have been modularized, facilitating rapid development of new promotional features. Future work aims to further componentize entire activity flows, allowing product teams to assemble new campaigns with minimal engineering effort.
Signed-in readers can open the original source through BestHub's protected redirect.
This article has been distilled and summarized from source material, then republished for learning and reference. If you believe it infringes your rights, please contactand we will review it promptly.
How this landed with the community
Was this worth your time?
0 Comments
Thoughtful readers leave field notes, pushback, and hard-won operational detail here.
