The architecture design behind the overall upgrade of the member system of support horse beehive

Time:2021-1-16

It’s no longer a secret that traffic dividends are coming to an end. In the Post Internet era, how to maintain the user group and improve the user experience on the platform is something that the whole industry needs to consider. It is for this reason that the whole industry is now paying attention to the construction of membership system, which is also one of the key investment directions of hornets nest in 2019.

In the face of this member market, which is gaining strength in the whole industry, it is no doubt that a higher requirement is put forward for the structural design of the member system to provide strong support for the member system with “honeycomb characteristics”.

The construction of the member system of beehive started in September 2018. With the rapid development of business, the company launched a more flexible, more dimensional and more rights member mode in order to let more users experience the high-quality member service of beehive in the first half of 2019. In this context, the initial rough underlying technology also needs to be adjusted in time to upgrade the core architecture and services.

1、 Membership strategy transformation

The early membership module consists of member products, user attributes and time attributes

We can see that the early member products are relatively single, so the product information is designed as a primary structure. The advantage of this design is that the logic is simple, it can be implemented quickly, but it is not easy to expand. Once there is a complex relationship between new member categories and different card types, the maintenance cost will double for both the project and the code itself.

Since the beginning of 2019, the member system of honeycomb has been comprehensively upgraded, which is mainly reflected in the following aspects:

  • More perfect customer acquisition channels, added the service display on the applet side;
  • Richer membership categoriesOn the basis of the original annual gold card and experience gold card, the quarterly gold card, 7-day gold card and “Fengxiang card” are added. In the future, monthly gold card and student card are planned to be launched;
  • Lower access thresholdIn order to make more users enjoy higher quality services, we have added ways to obtain membership by completing user incentive tasks, supplier cooperation, product tie-in, offline physical cards and so on.

This also means that the user’s membership will become more and more complex in the same period of time, and the early single membership strategy and model design can no longer meet the needs. When redesigning the membership, we made it clear that no matter how the business line divides the membership in the future, the underlying structure should be able to better support it, so we decided to separate the membership module identity. After upgrading the membership system, the product information is adjusted to take SKU as the minimum granularity, and the source of user information and access channel information are increased

2、 Member center architecture design and optimization

After defining the new membership strategy, we sort out the whole membership system and design the current member center architecture as follows:
The architecture design behind the overall upgrade of the member system of support horse beehive

According to the above architecture diagram, the current member center system is mainly divided into four parts: data storage, core service, interface layer and application layer

  • Data storage: mainly based on MySQL and redis, and the unified log system MES of hornet’s nest
  • Core servicesThis is the most important layer in the current member system of honeycomb. Core services can be divided into three parts

    (1) “Four carriages”: membership, rights and interests, value-added service access and membership points drive the operation of the whole membership system;

    (2) Transaction marketing: assist the four carriages to move forward quickly;

    (3) Support module: company level support module connected with member system, including risk control, monitoring, log, message bus, business settlement reconciliation, etc

  • Interface layer: the interface of member system exposed to the outside world, including membership, rights and interests, honey consumption, etc
  • application layer: mainly for C-terminal applications, including member channel page, honey center, user rights center, task center, etc

The following focuses on the core services layer.

2.1 “four carriages”

2.1.1 membership

At present, many common member products in the market adopt the common renewal mode, such as annual members and quarterly members of some video platforms. The characteristic of this mode is that it only distinguishes the time, enjoys the same rights and interests after the membership takes effect, and extends the validity of rights and interests by renewal.

However, due to the particularity of the business, the membership system needs to be designed more three-dimensional. If only the simple renewal mode is adopted, the user experience of high loyalty users will be affected.

  • First of all, in the same category of membership, the rights and interests of products with different duration are also different. Take gold card members as an example. Quarterly gold card and annual gold card can be upgraded by renewal, but they have different rights and interests. For example, the maximum discount of 96% for annual gold card is 500 yuan, while the maximum discount for quarterly gold card is 100 yuan.
  • In addition, the same user at the same time, as long as the conditions are met, they can have different types of cards, such as gold card and Fengxiang card.

In order to meet the above requirements, we decided to introduce the user identity superposition and renewal model. By adding the member SKU overlay and renewal relationship table, users can not only have multiple identities at the same time, but also renew existing cards in a period of time.

The architecture design behind the overall upgrade of the member system of support horse beehive

The above figure shows the timeline of membership. The horizontal axis represents time, and the vertical axis represents different card types. We can confirm the user’s current membership through the final SKU timeline.

We flatten each existing SKU timeline of the user. When the user sends a request to purchase a new card type at a certain time point, we check whether there are spus that the user is purchasing in the current effective timeline. If not, we stack them. If there are, we need to judge the configuration strategy between SKUs, decide whether to stack or renew them, and then continue to calculate the purchased SKUs Next, according to the configured rules, compare the identity relationship between the current purchase effective timeline and the existing SKU timeline to determine whether the user can complete the purchase, such as:

  • Pre identity: a SKU must be purchased before the current SKU can be purchased
  • Conflict identity: if you have purchased a SKU, you cannot purchase the current SKU

In order to meet different business needs, the overlay and renewal relationship can be configured through operation. The whole process is as follows:The architecture design behind the overall upgrade of the member system of support horse beehive

In order to make the user experience better, when we have multiple identities at the same time, we will adjust the weight of member SPU according to the data analysis results, and give priority to the rights with high weight. For example, if the current member has both a gold card and a ticket card, and the data shows that the utilization rate or attention of the gold card rights is higher than other products, the weight of the gold card will be increased, and the gold card identity and related rights will be displayed first when the user enters the member channel page.

2.1.2 equity Center

In addition to the identity system, the most important thing is the rights and interests of members, which directly reflects the different levels of members. At the beginning of the development of member projects, everything starts from scratch, and the requirements for expansion are not high. Every new identity and card type needs to be designed from the beginning. The development efficiency is very low, and the background configuration is also very scattered. Later, in order to support the rapid development of business, we began to consider splitting the equity center into two parts.

The first step is to build the equity poolThe following figure shows the basic model of equity pool:

The architecture design behind the overall upgrade of the member system of support horse beehive

We abstract the common attributes in membership rights and interests as the basic attributes that remain unchanged in principle, and form “equity materials” to be stored in the equity pool. The common attributes mainly include:

  • Equity types: there are mainly four types of Equity: exchange code, discount purchase, coupon and three party jump. At present, it can support all equity types in hornet’s nest
  • Suppliers: different suppliers provide different rights and interests, and even have different rights and interests access processes and rights and interests consumption processes. At the same time, different settlement modes of suppliers are involved
  • Distribution time: active or passive distribution, such as gold card 96% discount rights, is the core rights and interests of users to purchase members, which will be directly distributed to the user account after the user purchases the card. Other rights and interests, such as airport VIP Hall, QQ green diamond, Tencent video quarter card, need users to take the initiative to receive.
  • Basic attributes: the basic attributes of equity depend on the equity type, distribution timing and supplier. That is to say, different suppliers or different equity types and distribution timing will combine different equity basic attributes. Most of the attributes here are the fixed attributes of these equity. Finally, these four attributes constitute the basic equity material.

The following figure shows the process of user card opening and rights and interests issuing

The architecture design behind the overall upgrade of the member system of support horse beehive

When the payment of member products is completed, the member center will notify the rights and interests center to issue rights and interests; the rights and interests center will notify the preferential center after filtering rights and interests, and the preferential center will eventually complete the issue of passive rights and interests; the rights and interests that need to be actively received by users will only be issued to users, and the final decision is made by users.

The second step is the allocation of equity rules. With the foundation of the first step, the member center configures the corresponding equity rules for the equity materials in the equity pool, and then displays them to users.

The architecture design behind the overall upgrade of the member system of support horse beehive

Equity rules are mainly divided into:

  • Conditional rule: it refers to some basic premises for determining the rights and interests, mainly including membership, source of prior request, current business, etc
  • General rules: refers to the standards of external display, including copywriting, sorting, online and offline time, rights and interests description, etc
  • Operation rules: This is the most changeable part of the equity rules, and also a part of the refined operation of the equity center. Different user identities have different rights and interests prices, exchange prices and different tags, which show the user’s identity privileges differently

We abstract the common attributes in the rules of rights and interests, and form a unified standard for the external display of rights and interests. Of course, only general equity rule configuration is far from enough. Therefore, on the premise of not affecting the core equity rules, the configuration of extended rule template is added in the background, so as to meet the needs of different rules of special equity, realize dynamic rule configuration, and use more flexibly.

2.1.3 third party rights access

Part of the rights pool is station rights, such as 96% discount for core gold card products, hornet’s nest coupons, transfer machines, etc. The distribution and consumption of these rights and interests are completed under the unified rules established in the station, which is relatively easy to access.

Part of the rights pool is station rights, such as 96% discount for core gold card products, hornet’s nest coupons, transfer machines, etc. The distribution and consumption of these rights and interests are completed under the unified rules established in the station, which is relatively easy to access.

The other part is the off-site rights that need to be accessed, that is, the value-added services provided for members, such as airport VIP Hall, travel insurance, etc. Different third parties have their own particularity of rights and interests rules. At present, they can’t be abstracted into a unified standard, and they can’t be accessed by OpenAPI.

At present, we integrate the access of the third party’s rights and interests in the process, and finally form two kinds of ways:

  • One is that the claim of rights and interests is completed in the hornet’s nest. All the operations of the user are completely carried out in our application. After the completion, the third-party interface is called asynchronously to issue rights and interests for the user.
  • The second type is that the claim process is completely carried out in the third-party system, mainly for some points exchange rights. After the user clicks to claim the rights and interests, he jumps to the third party page. After the interaction is completed, he calls back to the hornet’s nest interface asynchronously, and the hornet’s nest system will increase or reduce the points according to the callback situation. The disadvantage of this method is that the user experience is completely determined by the third party, and the controllability is not high; but the advantage is that it can quickly access some complex rights and interests play methods, such as some game rights, and avoid investing a lot of energy in development.

The architecture design behind the overall upgrade of the member system of support horse beehive

The above figure is a flow comparison diagram of the two collection modes. It can be seen that the three-party docking in each step is carried out in an asynchronous way. In this way, when the third-party system is abnormal, the normal service of the horse cell will not be affected, and the system availability will be guaranteed.

2.1.4 membership points

The growth system is very important for building a complete membership system, and the hornet’s nest based on the content community has a natural advantage in this respect. We decided to introduce the existing user scoring system “honey” to carry part of the member scoring function. Through opening up with the member center, we can enhance the online interaction with the member users, and improve the user activity and stickiness. Under different honey scenarios and honey strategies, users can earn points and exchange the required rights and interests after meeting the corresponding conditions. In addition, we are also expanding more ways to combine honey with b-end, hoping to promote win-win results of the platform and businesses.

The architecture design behind the overall upgrade of the member system of support horse beehive

The picture above shows the services provided by the honey center and some short-term plans of the membership system. How to make good use of the incentive mechanism to make the whole membership system more perfect and achieve more refined operation for member users is an important topic for the deepening of the “content + trading” strategy of hornet’s nest, which is also the direction that the R & D team needs to constantly explore.

2.2 performance optimization of marketing activities

After the transformation of membership, rights center, third-party rights access and honey center, the member center has also completed the first step of upgrading.

In order to let more users understand the membership mechanism and experience the membership rights, we have launched a lot of marketing activities. Many of them have the scene of second killing. The following part focuses on the technical optimization to ensure the stability and reliability of these marketing activities.

2.2.1 concurrency control

In the second kill scenario, it is necessary to prevent oversold caused by high concurrency. There are many mature solutions to this problem, such as pessimistic lock, distributed lock, optimistic lock, queue serial, redis atomic operation and so on. Of course, the most ideal solution is to use distributed lock.

Considering the current concurrency level and technical cost, we decided to use MySQL optimistic lock to realize the seckill function at this stage. As we all know, the same row of database internal update is not allowed to be concurrent. Only when the row is updated will it be released. Our scheme is to prevent oversold by adding a unique version: judge whether the version number is consistent with that in the database every time the data is updated; if it is inconsistent, it indicates that the current inventory has been occupied by other users, and an exception is thrown; if it is consistent, it completes the current user’s occupation of the inventory.

2.2.2 flow peak clipping

In order to alleviate the pressure of database caused by the burst of instantaneous traffic, we must first identify the scenarios that will cause the sharp increase of instantaneous QPS.

One is that the interface is maliciously redrawn. Because our second kill business requires users to log in, the possibility of forging session is low. Therefore, if this happens, it is likely to be caused by the same uid traversal interface. Here, we only need to add the redis lock of uid, so that a uid can only pass through one request in a certain period of time, so that the vast majority of traversal brushing interface behavior can be stopped.

Another situation is caused by traffic burst. It may be that there are a large number of real snap up users, or the other party uses a large number of device requests. This is the actual scenario we are facing. As we mentioned earlier, MySQL optimistic lock is added to avoid oversold. If the instantaneous traffic is huge, MySQL’s reading and writing, table locking and other phenomena will be more serious. When the database pressure reaches the limit, it will be suspended. Therefore, in order to reduce the transient pressure of the database, we need to do a good job of current limiting in the service layer. For example, when there are only 1000 pieces in stock, but 1W requests are sent to the database, the following requests are meaningless. We know that whether it’s Memcache or redis, it won’t be a big problem for a single machine to carry 10W requests per second. Therefore, in the case of not completing the distributed lock, we use redis to do the most basic flow limiting, so that most requests are intercepted in the service layer, and only a small number of requests will penetrate into the database.

The architecture design behind the overall upgrade of the member system of support horse beehive

The figure above is a simple flow chart of the current seckill system. In the future, if such member marketing activities are still the focus of business, we will use redis distributed lock to optimize and build a more perfect second kill system.

2.3 risk control

The part of support module mainly shares the content related to risk control. In order to ensure that the real users enjoy the membership service, we need to identify and resist the potential risks brought by the black industry, ensure the normal operation of the system, and strictly control the losses.

The architecture design behind the overall upgrade of the member system of support horse beehive

The figure above shows the structure of security control in the current membership system. The API routing layer is mainly responsible for data collection and risk estimation, and the collected data is uniformly written into the company’s log system MES for storage. We use the current limiting method of sliding window mode. When the total traffic exceeds a certain threshold, we will record the large traffic or too fast requests to the member suspected blacklist table, and then carry out the current limiting processing of the routing layer and access to the company level risk control system. According to the identification of different business scenarios, we adopt the relevant risk control strategy; finally, we will notify the routing layer by e-mail, SMS and other means The corresponding person in charge of the technical department should deal with it as soon as possible.

3、 Summary and Prospect

We have accumulated a lot of valuable experience in the process of building the member system architecture of honeycomb, among which the deepest feeling is to avoid blind optimization. In the reconstruction of the system level, we should first focus on the upgrade of the core framework and the evolution of the technical system with the business as the guide, and do not get lost because of the excessive technical details.

In the future, we will actively investigate and apply more mainstream and cutting-edge technologies, such as the introduction of member tags and user portrait systems, so as to make good use of these technologies and make the member center play a greater value.

Author: R & D team of e-commerce member project

Colored eggs

Welcome to pay attention to maHoneycomb technology official account background, and for this articleActively leave messages, express opinions or conduct more relevant technical exchanges.As of 7:00 pm on July 27We will screen the highest quality messages from the official account.Seven readers present hornet’s nest quarterly gold cardDon’t miss it! (scan below the two-dimensional code to pay attention to the official account)

The architecture design behind the overall upgrade of the member system of support horse beehive

Recommended Today

DK7 switch’s support for string

Before JDK7, switch can only support byte, short, char, int or their corresponding encapsulation classes and enum types. After JDK7, switch supports string type. In the switch statement, the value of the expression cannot be null, otherwise NullPointerException will be thrown at runtime. Null cannot be used in the case clause, otherwise compilation errors will […]