How to consider concurrency when making a snap-up function

The company wants to create a rush purchase function
How to avoid excess orders caused by concurrency?
Because the database is mongo, it cannot lock like mysql
I don’t know any good solutions?

All I want is to use redis to force him to queue up, but this is too nonsense...
I will check it every time I create it, but I am afraid of that little concurrency...

Reply content:

The company wants to create a rush purchase function
How to avoid excess orders caused by concurrency?
Because the database is mongo, it cannot lock like mysql
I don’t know any good solutions?

All I want is to use redis to force him to queue up, but this is too nonsense...
I will check it every time I create it, but I am afraid of that little concurrency...

Using message queue can solve this problem

First of all, you must have a design capacity. Your project is prepared to accommodate as many people as possible to grab as many products. Then decide what technology to use.
If there are only 10 people grabbing it, don’t worry, just find a relational database and it’s done.
With more, you can put the pressure directly on mongodb. By the way, mongodb is not lock-free. You can lock it and not sell more if you use it reasonably, using the $inc operator. For example:

db.product.update({sku: 'xxx', qty: {$gt: 0}}, {$inc: {qty: -1}})

If this is not enough for you, it’s time to consider queuing

This need to snap up involves financial functions, and financial functions definitely require lock functions.

So, if you are good at it, write your own middleware. If you want to be lazy, just use mysql.

Make a separate table just to store this kind of rush-buying products

Redis should be able to achieve it. Redis itself is single-threaded, and its operations are naturally serialized, so there is no need to worry about concurrent access. Of course, using mysql is a convenient choice.