Distributed lock still require waiting in the end? [closed]

Question

Closed. This question needs to be more focused. It is not currently accepting answers.

---

Want to improve this question? Guide the asker to update the question so it focuses on a single, specific problem. Narrowing the question will help others answer the question concisely. You may edit the question if you feel you can improve it yourself. If edited, the question will be reviewed and might be reopened.

Closed 3 days ago.

Improve this question

There are many articles suggesting the use of Redis-based distributed locks in concurrent environments.

But in the end, don’t they still require waiting?
Let’s say we’re using a Spring Boot application. We use an asynchronous Redis client like Redisson or Lettuce to implement a distributed lock, using a product ID as the key. In this scenario, multiple users are trying to purchase the same product, and the stock quantity must be updated in real-time.

Through load testing, we confirmed that our legacy system using pessimistic locking causes serious issues under high concurrency. So we considered using distributed locks instead — but the underlying mechanism still seems to involve waiting. For example, if 400 request threads come in at the same time, wouldn’t 399 of them still have to wait for the lock to be released?

So my questions are:

1. When and in what situations should distributed locks actually be used?
2. In high-concurrency environments like this one — where real-time inventory updates are required — what’s the right approach?

The legacy system is throwing errors under the pessimistic locking mechanism.

• Iłya Bursov: yes, 399 will have to wait, distributed locks are used when multiple different processes have to access/modify shared data, like they all have to check actual stock level
• Lior Kogan: I'm not sure what you're asking. If you want to lock, then you need to lock ;-). Optimistic locking may be a valid tradeoff for your use case. What are the chances that two users will add the same item to their cart?
• leeeleee: Oh, I'm not good at explaining. I've looked at controlling it because there's a lot of room for conflict in real-time synchronic environments. Pessimistic locks on legacy systems are becoming a problem. So I thought about technologies like distributed locks or event systems, and in the case of distributed locks, I thought "waiting" is the same anyway as above.
• Lior Kogan: This is what locks are about. If someone hold the lock, others would have to wait ;-) Maybe you should start with describing the desired behavior.
• leeeleee: Aha I think this question came up because I thought distributed lock would be just fast. Whether it was pessimistic or distributed lock, I know it's a Redis-based lock, but I expected it to be fast because it's a Redis-based lock. However, as you said, in the end, what I want is a proper way to manage inventory in many QPS situations. Is the kafka-based consumer system right to achieve what I want?