Pessimistic Locking is when you lock the record for your exclusive use until you have finished with it. It has much better integrity than optimistic locking but requires you to be careful with your application design to avoid Deadlocks.

It is based on the principle that if anything might potentially go wrong, it’s better to wait until a situation is safe again before doing anything (Similar to mutual exclusion in Multi-Threading)

RDBMS systems like Postgres, MYSQL, and ORACLE all provide ways of doing this.

Even ORMS like Spring Data JPA have a simple way of doing it. This article explains in detail more about this

https://www.baeldung.com/java-jpa-transaction-locks#:~:text=When%20using%20Pessimistic%20Locking%2C%20the,specify%20the%20lock%20timeout%20value.

Now Between the above two, we would assume that all issues will be solved but that’s where the complexity kicks in

What happens in a distributed system

A Lock in a distributed environment is more than just a mutex in multi-threaded applications. It is more sophisticated and complex because now this lock can be acquired by different nodes in the system and any of them can fail. This increases the complexity manifold as we need the rest of our system to still work flawlessly even if one or more nodes fail.