SKR Shop is a group of low-level code farmers. Due to the mental disorder tortured by the project at work, and due to the pride of programmers: the system designed by others is shit, my design is the best in the universe, so I decided to make a design without coding e-commerce design manual.
Project Address:Github.com/skr-shop/ma…
For an e-commerce, shopping cart is the most important step in the whole purchase process. Because the development of e-commerce to today’s shopping cart is not only to complete the function of packing orders; It is also an important display window for collection, comparison, promotion reminder and relevant recommendation. With so much capacity, how can we design shopping carts to ensure high performance and good scalability to meet future development?
Today we start with a hypothetical scenario to output a shopping cart design: xx e-commerce platform is a multi-tenant mode (many of our previous designs are multi-tenant mode), users can add goods to the shopping cart, and show and sort according to the latitude of the merchant. Of course, the shopping cart also supports normal operations: select, delete, empty, deactivate, etc. And there are promotions to remind users. At the same time, in order to monitor and operate, it is necessary to support the synchronization of shopping cart data to monitoring and counting warehouses.
This article will explain the capabilities of the system from both the user perspective and the server perspective. The main purpose of this article is to explain shopping cart capabilities and some logic. In the next chapter, we will design the shopping cart model and define the interface.
User perspective
Let’s first define the functions of the shopping cart on the user side.
The basic capabilities of a shopping cart are shown in the figure above, and we’ll break them down one by one.
operation
From the user’s point of view, shopping cart for users can add goods to the shopping cart (add shopping cart, immediate purchase belong to a way of adding); After adding to the shopping cart, you can delete the product (delete one, delete more, empty) if you do not want it. If you want to buy more, you can modify the purchase quantity, and if you find that the money is not enough, you can reduce the purchase quantity. Or find that red is more beautiful than white, you can easily change the specifications in the shopping cart; For some expensive items, you can add some guarantee service to your shopping cart (which is actually a bundled virtual good); When it comes time to settle accounts, it will also provide the ability to choose which items the user really wants to buy.
From the above description we can see that this process is intrinsically related. Here to say about the selected function, the industry has two ways, each has its own advantages and disadvantages, we have a look. The selected status of Taobao products is saved in the client, and is not selected by default. The status of refreshing and re-opening the APP will disappear. Jingdong and Suning are stored on the server and record the status of the user’s selection. There are pros and cons to both cases.
Client:
- Performance, selected/unselected logic is done locally, reducing network requests
- Experience, multiple points can not be synchronized, but the shopping cart is relatively more like a favorites, every time the user chooses it is not wrong
- Calculation, price calculation needs to upload locally selected goods (can also be calculated locally)
- Implementation, mainly rely on the client to achieve, independent of the server, research and development decoupled
Server:
- Performance, each operation selected requires the server to call, and this operation may be very frequent, in addition to network loss, the server also needs to consider how to quickly find the modified goods
- Experience, multi-terminal synchronization status, record historical status
- Computing, the server can obtain the data, no need to upload additional data on request
- Implementation, server and client need to agree on how to interact, and return data (price changes with each selection), coupled together
In my opinion, neither of these two methods has obvious advantages. It is a choice based on business model and team situation. Our subsequent design here will be based on saving the item selection state on the server side.
In the whole operation logic, there are two more important places to explain separately: the purchase method and the shopping car to modify the purchase attribute
Buying patterns
The main purchase methods are immediate purchase, add shopping cart, group purchase three ways.
First of all, there’s not much to say about regular addition to the shopping cart. Focus on the immediate purchase and group.
Buy now is operationally the process of selecting an item and going straight to the order confirmation page, without the shopping cart checkout step. But its implementation can rely on the logic of the shopping cart. Let’s take a look at the difference between implementing this logic with and without a shopping cart.
If you use a shopping cart, where the user clicks Buy Now, the item is essentially added to the cart, but the cart is different from the prototype cart because it can only add one item and is overwritten with each action. The visual Angle effect is also directly from the product details page to the order confirmation page. Let’s see the benefits of this approach
- With shopping cart in order confirmation, order logic consistent, internal can be directly through shopping cart to obtain data
- This requires a separate shopping cart dedicated to one-click purchases, which consumes memory
Another implementation uses a new data structure, because one-click buying is generally simpler, requiring only product information and price information. Each interaction can be obtained based on sku_id.
- The logic of order confirmation and ordering needs to be modified, and the agreed parameters need to be passed between each request
- Memory saving, up-down interaction is guaranteed by sku_id
We will implement this in the form of a separate shopping cart using one-click purchases on the server side. The consistency of data model of shopping cart ensures the consistency of subsequent processing process.
For the group, he actually divided into two parts, the first is the action of opening the group, when the group is established. We can choose to add a bunch of items to the regular shopping cart, and we can also add other items. You can also choose to add a group of goods to the one-click shopping cart to ensure that only one group of goods can be bought. The group mode is more like a prerequisite for adding to the shopping cart. It has no effect on the design of the shopping cart per se.
Modify purchase attributes in the shopping cart
This mainly refers to the convenience of doing things in the shopping cart that need to be done in the SPU latitude, such as changing specifications (i.e., changing skUs) and selecting services bound to the SPU latitude (insurance, extended warranty, etc.).
Let’s focus on the service you choose to bind to. For example, when we buy a mobile phone, the manufacturer offers an extended warranty and various other add-ons, which are generally virtual goods. But there’s a special case. These services cannot be purchased separately, and they are closely related to the quantity of the main product. For example, if you buy two mobile phones, the number of these services must be 2, which will be a linkage relationship.
These guarantees cannot be purchased separately, but must be bundled with specific products.
The server must consider how to preserve this hierarchy when storing this data, as we will see later in the model design.
remind
Promo alerts are simple, return shopping cart data, and each item should carry the current promo information. This section focuses on how to get the promotion information, which will be seen on the server side.
Then there is the cart count reminder, which shows the number of items in the cart. Generally speaking, entering the APP will call an interface to get the user’s number of unread messages, the number of items in the shopping cart, and so on. Here is the need for very high read speed. So how can this need be met?
Scheme 1: We can design a structure to store the amount of such reminder information related to the user, and read this data directly each time. You don’t have to deal with a messaging service, a shopping cart service to get this data.
Scheme 2: Design a field to store the total quantity in both message and shopping cart models. In the interface that reads data, call these services in a concurrent way to get the data and then aggregate it, so that the speed only depends on the slowest service.
Here, we will adopt plan 2 in our design, because efficiency can be guaranteed to some extent, and the consistency of structural data of the whole system can be more easily guaranteed. Of course, there is a fine line here: concurrent reads must be designed to time out, so that the performance of the entire interface is not slowed down by a single service reading problem.
Next, let’s look at promotion. In addition to reminders, this part also needs to provide corresponding entrances for users to complete the operation of promotion. For example, a commodity has a voucher, so you can directly provide access to receive; Can gather together, have entrance to enter the list and select goods, etc. This part of the problem is how the server can get these promotions from the product latitude in a timely manner.
Having looked at it from the user’s point of view, let’s look at what needs to be done on the server side from a development perspective
Research and development perspective
Let’s start with a summary of the requirements:
storage
For storage, the first choice is definitely memory storage, as to whether to drop library, I don’t think it is necessary. Here are my reasons:
- The data of shopping cart changes very frequently and the cost of dropping is relatively high. It is difficult to guarantee consistency if the shopping cart is dropped asynchronously
- In extreme cases, the cache crashes, requiring only the user to rejoin the cart, and data recovery can be guaranteed through the cache persistence mechanism
So for the shopping cart, we just keep the data completely in memory.
The type of goods sold has changed
Now let’s talk about the change in the type of goods being sold. What does that mean? Think about it for A moment: Let’s say I add item A to my shopping cart, but I never pay for it. At this time, the operator said to hold an activity for product A and take out 10 stocks at A 50% discount. So the question is, what do you do with people who already have this item in their cart? The main problem solved here is that users who have the item in their cart cannot buy it directly at a 50% discount. Several schemes, let’s take a look:
Scheme 1: After promotion configuration, all users with the product in the shopping cart will be invalid or deleted. This scheme will be passed first, with high operation cost and poor user experience
Scheme 2: The same SKU and different sales types should be distinguished in the shopping cart. That is to say, instead of adding items according to SKU latitude in our shopping cart, we generate a unique identifier by SKU+ sales type.
It can be seen that scheme 2 solves the problem that the same SKU can coexist in the shopping cart without affecting each other before inventory. But there’s another question here, right? The type of goods sold (or this mark), how and where to set? It seems that the product system can be designed and the promotion system can be set up. Our logic will be configured in the promotion system. Because goods belong to basic logic, if changed, global inventory will be affected. It is difficult to sell automatically after the event. Therefore, the tag should be set in the activity (when set in the activity, the promotion system will know if the previous activities of the item are mutually exclusive to ensure that the configured activities do not contradict each other).
Rely on the system
The shopping cart system relies on many other systems.
- Commodity system
- Inventory system
- Promotion system
- Settlement system
These depend on systems, some for data transmission, some for data acquisition. Let’s look at these two latitudes.
Promotional reminders and calculations
The server side is to solve the promotion reminder and price calculation problems.
Now for the calculation, the best way for this part is to call the price calculation of the clearing center. Let’s look at the difference between the price calculation in the shopping cart and the price calculation at order settlement.
First, the cart does not know the user’s address when calculating the price, which will affect the calculation of freight; And then you don’t know how to use the coupons. So in fact, if we solve these two problems, we can make the price calculation from the same logic, just some of the inputs are different. Therefore, we can calculate according to the highest freight, and coupons are not used in the shopping cart by default. For the promotion problem, we can confirm the price of the selected goods through the promotion system. So the price of the promotion should be included.
Next, we will talk about how to effectively provide promotional information for users. Let’s start with our configuration view.
When we configure a promotional activity or issue a coupon, we always put multiple commodities under a promotional activity or coupon. It is relatively more efficient to obtain goods according to the latitude of activities and coupons.
But there is a change in the shopping cart scenario. We need to obtain all the activity information of the product from the latitude of the product (all platform activities, shop activities); So what do you do to display this information in your shopping cart? It’s a common practice (and many companies do) to pull out all the activity information and iterate through all the information related to the product. This approach is inefficient and cannot meet large-scale application scenarios, such as during Singles’ Day.
Therefore, in order to meet this requirement, the promotion system needs to provide an ability to obtain corresponding promotions (events, coupons) by item. Therefore, in general, promotional system configuration activities can not only be stored by activity latitude, but also need to generate a product latitude promotion information.
Shopping cart data analysis
In the case of shopping cart data, the front end adds shopping cart data through buried records, but front-end buried records typically trigger a front-end action without knowing whether the action was successful or not. And the inability to keep track of the current overall shopping cart data.
In order to let the operation team have a more complete understanding of the current situation of the shopping cart, we log local logs through the back end, and then synchronize logs to data, monitoring and other services through log collection.
Failure and sorting
There are still two parts left unmentioned. One is how the goods should become invalid, for example, the stock is out of stock and the goods are removed from the shelves. Second, the goods in the shopping cart are from multiple stores. What is the sorting strategy?
Since this article is only about requirements, not specific model design, it is only about scenarios. The first is the failure of goods, which is like a soft delete operation. Once set, the goods seen by the user side will not be able to be settled, but can only be deleted.
The design we would use for sorting is that the most recent action must be at the top, based on when the last action was taken by a particular store in the cart.
At the end
From the above we have basically figured out what we need to do in shopping cart design and what capabilities the system we rely on should provide. The next part starts to enter the design of data model and the interface design of front and back end.
If you have any additional requirements on the shopping cart, please leave a comment. Let’s improve it together.
Project Address:Github.com/skr-shop/ma…