Principles and Precautions of the Flash Sale System

The same is true for flash sales. Flash sales often lead to thorny problems such as high concurrency, system downtime, and oversold inventory. As developers, how can we prevent business risks while ensuring system stability?

This article discusses several principles and points to note for flash sales plans. The mind map is at the end of the article.

In Principle

Looking at the various flash sale plans, no two are the same, but they all follow the same principles. The specific principles are as follows:

(1) Protect the database

In the flash sale scenario, database protection must be prioritized. This is the top priority. Once the database goes down, the system will be completely paralyzed, causing losses to business and reputation. Pay attention to the following points when protecting the database:

• At the application layer, all unqualified requests need to be intercepted to prevent the logic from reaching the database.
• Evaluate the number of concurrency, QPS, etc., and set a reasonable number of database connection pools for the application to avoid exhausting the database connections.
• Monitor the database, observe the CPU, memory and other pressures of the database, observe slow SQL, etc., and respond promptly if any problems occur.

(2) Protecting application systems

The application system is also an object to be protected. Whether it is a single unit or a microservice, the system should not go down as much as possible. When protecting the system, pay attention to the following points:

• If conditions permit, make the BFF layer of the flash sale system an independent service, so that even if this service fails, it will not affect other services.
• Evaluate the traffic of flash sales and appropriately increase the load of some microservices to improve the system's responsiveness.

(3) Early Exit

Once the flash sale system is open to the public, it will definitely attract a lot of freeloaders and even malicious attacks. Therefore, when processing the logic, it is necessary to do a pre-check and interrupt it directly if an illegal request is found.

If conditions permit, some offensive tests and stress tests should also be performed to see if illegal requests can be blocked and whether the system can withstand the pressure.

(4) No overselling

Products sold in flash sales usually lose money to gain publicity, and every sale is a loss. Generally, the products, prices, and inventory of flash sales are the result of communication and confirmation between the company's operations and management.

In order to control losses within a reasonable range, sales must be strictly in accordance with the established inventory, and overselling must not occur.

Main points to note on the front end

In the flash sale scenario, there are some points to note on the front end, as follows:

• Page staticization: Whether on PC, H5, mini program or APP, the page should be as static as possible, cached if possible, and request interfaces as little as possible.
• CDN: refresh the involved js, pictures, html and other static resources to CDN in advance to speed up access.
• Reading data from the cache: The interfaces used in flash sales scenarios should be distinguished from regular interfaces. The interfaces in flash sales scenarios try to read data from the Redis cache and then respond to the front end. The front end also needs to determine which data can be stored in the front end cache to avoid repeated interface calls next time.
• Intercept at the front end: The front end page also needs to do some interception to filter out illegal requests. Although it is not very effective and can only prevent gentlemen but not villains, it still needs to be done. All actions that can intercept illegal requests in advance should be done.

Backend main points to note

There are many things to note about the backend, which are roughly as follows:

(1) Elastically increase servers: appropriately expand the load according to the overall deployment situation. For example, in the case of hybrid cloud deployment, you can temporarily rent several cloud vendors’ cloud servers as needed and release them immediately after the event ends, which minimizes costs.

(2) Current limiting and downgrading: Whether in flash sales or other scenarios, the means to protect the system are current limiting, downgrading, and circuit breaking. No matter when, these three methods are used.

(3) Pre-verification: Pre-verification can block illegal requests to the greatest extent possible, such as verifying malicious duplicate IP addresses, verifying duplicate orders from users, verifying inventory, etc.

(4) Cache preheating: For product information and inventory of flash sales, cache preheating is required in advance, such as flushing the data to the Redis cache in advance.

(5) Scheduled tasks:

• Timely release of inventory: In general scenarios, it may take half an hour to cancel unpaid orders. However, in flash sales scenarios, due to limited inventory, to avoid malicious inventory occupation, the time allowed for unpaid orders must be reduced, such as 3 minutes. In this scenario, you can use a scheduled task to cancel the order in time, or use a scheduled message solution of a message queue (such as RocketMQ's delayed message).
• Calibrate cached inventory: Placing an order will occupy inventory, and canceling an order will release inventory. If the inventory is preheated to Redis, a scheduled task is required to calibrate the inventory quantity in Redis.

(6) Placing orders and reducing inventory:

• Optimistic locking to reduce inventory: When updating the inventory quantity in the database, be sure to use an optimistic locking solution to avoid overselling, similar to update ttt set stock = xxx where product_id = yyy and stock = zzz;.
• Synchronous or asynchronous: After completing the pre-logic, the order placement and inventory reduction logic will be entered. At this time, it can be called directly in a synchronous way or asynchronously thrown into MQ. The specific method to be used needs to be evaluated based on the system throughput.

Summary

This article mainly discusses several principles of flash sales and front-end and back-end considerations. There are thousands of plans, but only a few principles. Finally, here is a mind map for easy memorization.