Revamping MaFengWo’s Membership Platform: Architecture, Identity & Performance

As traffic dividends fade, MaFengWo recognized the need for a robust membership system to retain users and improve platform experience, making membership architecture a 2019 priority.

Part 1: Membership Identity Strategy Transformation

Initially the identity module combined product, user attributes, and time attributes in a single‑level structure, which was simple but hard to extend.

In early 2019 the system was upgraded with more acquisition channels, richer membership categories (quarterly gold, 7‑day cards, "FengXiang" cards, etc.), and lower entry thresholds such as task‑based acquisition and partner offers.

More acquisition channels , including mini‑program service displays.

Richer categories , adding many new card types.

Lower thresholds , allowing acquisition via tasks, partner deals, bundled products, and offline cards.

To accommodate the growing complexity, the identity module was extracted and redesigned around SKU as the smallest granularity, adding source and acquisition‑channel information.

Part 2: Membership Center Architecture Design and Optimization

The current architecture is divided into four layers:

Data storage : MySQL, Redis, and the unified log system MES.

Core services : the "four horsemen" (identity, benefits, value‑added service integration, points), transaction marketing, and supporting modules (risk control, monitoring, logging, message bus, settlement, etc.).

Interface layer : APIs for identity, benefit claim, honey consumption, etc.

Application layer : C‑end features such as membership channel page, honey center, rights center, and task center.

2.1.1 Membership Identity

Unlike simple time‑based renewals, MaFengWo supports multi‑card ownership and tier‑specific benefits. SKU overlay and renewal relationships allow users to hold multiple identities simultaneously and renew existing cards.

The timeline diagram shows how each SKU occupies a time axis, enabling the system to determine the current effective identity.

Configuration rules define pre‑condition identities (must own a certain SKU before purchasing another) and conflict identities (cannot own two conflicting SKUs together).

2.1.2 Benefits Center

The benefits pool abstracts common attributes into immutable "benefit materials" stored centrally. Core attributes include benefit type (redeem code, discount, coupon, third‑party redirect), supplier, issuance timing, and basic properties.

When a user completes payment, the membership center notifies the benefits center, which filters and forwards to the discount center for passive benefits or directly grants active benefits to the user.

Benefit rules are divided into condition rules (identity, source, business), common rules (display text, ordering, validity), and operational rules (price, exchange rate, tags) to enable fine‑grained, dynamic configuration.

2.1.3 Third‑Party Benefits Integration

Two integration patterns are used:

Benefits are claimed inside MaFengWo; after user action, an asynchronous call delivers the benefit to the third‑party system.

Benefits are claimed entirely on the third‑party site; after completion, the third‑party asynchronously notifies MaFengWo to adjust points. This approach offers rapid integration for complex third‑party offers.

2.1.4 Membership Points

MaFengWo leverages its existing "Honey" points system to provide membership points, encouraging user interaction and loyalty. Users earn points through various Honey scenarios and can redeem them for benefits, while B‑side collaborations are being explored.

2.2 Marketing Activity Performance Optimization

2.2.1 Concurrency Control

To prevent overselling in flash‑sale scenarios, MaFengWo initially adopted MySQL optimistic locking by adding a version field; updates succeed only when the version matches, otherwise an exception aborts the transaction.

2.2.2 Traffic Shaping

Redis‑based rate limiting is used to block abusive repeated requests (UID‑level lock) and to throttle burst traffic before it reaches the database. A simple flow diagram illustrates the current seckill process.

2.3 Risk Control

The risk‑control module sits at the API routing layer, collecting data into the MES log system and applying sliding‑window rate limiting. Excessive traffic is flagged, added to a suspected blacklist, and processed by the company‑wide risk engine, with alerts sent via email or SMS.

Part 3: Summary and Outlook

The key takeaway is to prioritize business‑driven refactoring over blind optimization, focusing on core framework upgrades and technology evolution. Future plans include adopting member tags, user‑portrait systems, and other cutting‑edge techniques to further enhance the membership center’s value.