I’m having some trouble understanding the need of a distributed lock. I did think of an example where it may be required but I’m not completely sure. I would appreciate some comments if I’m thinking in the right direction or not.
Example Scenario:
In an app that allows you to book movie tickets and pick the seats you want to reserve, two users may be trying to reserve the same seat. It is possible that User1 has paid for their seats but the available seats has not updated yet. User2 would be allowed to book this already reserved seat.
Solution:
With a distributed lock, User1’s client can obtain the lock for that seat the moment they start their checkout process and only release the lock once the available seats have been updated.
Follow up:
In a case where a user abandons their checkout and exits out of the app without cancelling, is using a TTL for this lock a good idea?
Also, this is my first time asking a question here so please let me know if I can improve my questions in any way.
I did try reading up online about Distributed Locks but I couldn’t find a good real-world example.
3
Your approach to the problem is typical (which is good) – booking sites often mark seats “in-process” with a TTL attached to make sure the purchasing process has some time limit to it (and account for customers who just walk away). Btw, this is a a popular system design interview question “please, design a ticket master” – there are many youtube videos on this topic.
I would like to focus on the question “do you need a distributed lock?”.
You are right – you need a lock. There are many flavours of locks and some of them would fall in a “distributed lock” bucket. At the end of the day, it will depend on your system’s architecture. Let me give you a few examples:
Let’s say your system has a single SQL database and every seat is a row in a table. In this case, you could totally lock those rows/seats by using transactions, something like “select for update”.
Clearly, the previous example is not a “distributed lock” – there is a single point in the infrastructure – the database table – where all requests/updates meet and this is the one point where the application may make decisions.
What if your data layer does not support transactions? How could you deal with locks then? As an option, you could install a dedicated lock service and use it to lock seats.
Your external lock service may or may not be a distributed one. That a choice to make. For example, you could have a dedicated ACID compatible data store to use as non-distributed option, or something like ZooKeeper for distributed one. This is usually a trade off between availability and cost and complexity.
A distributed lock system would operate on several nodes/computers/servers – this would make it distributed. And the main challenge would be the data consistency.
For example, let’s say our system has ten nodes, and two customers are connected to two different nodes. If both customers want to get the same lock – clearly – only one should get it. This is where the consistency view of the data is required.
Just a few directions to explore(these are popular questions):
- how to do a lock with zookeeper (zookeeper is a distributed system)
- linearizability of a system – an important property to make sure every operation sees the consistent view of data
- raft is a reader friendly consensus protocol, which one may use to build a resilient distributed lock service
1