While researching about ways to make my application more production-ready, especially in situations where multiple users may interact with the same data, I came across a concept called Optimistic Locking.

Optimistic Locking is a concurrency control strategy commonly used in transactional systems to prevent data inconsistencies when several users attempt to update the same resource.

For now, this post will be more theoretical than practical. The goal is to explain what problem exists and how it can be handled conceptually.

I will get into the technical implementation details in a later post.

Scenerio

Let’s say you have two users managing product entries on a website.

Here’s the sequence of events:

• User 1 opens a product and starts editing it.
• They step away for a break without saving their changes.
• User 2 opens the same product five minutes later.
  • From their perspective, no changes have been made yet.
• User 2 edits the product but gets interrupted and forgets to click Save.
• User 1 comes back, completes their edits, and saves the product.

So far, everything looks normal.

Now imagine User 2 later clicks Save.

What really happens now?

• Without any concurrency control in place:
• User 1 successfully saves their changes

The problem here is that:

• both users made valid changes
• neither user is aware of the conflict
• there is no clear trace of where the error originated
• User 2 also saves their version afterward
• User 1’s changes are overwritten, even though they were correct
• The final product entry contains incorrect or incomplete information

Why this is a problem in Production Systems?

In a production ready system, we want to

• protect data integrity
• avoid silent overwrites
• clearly detect and handle conflicts

And this is where optimistic locking becomes useful.

Optimistic locking is a strategy that assumes conflicts are possible but relatively rare.

Instead of locking a record as soon as a user starts editing it, the system allows multiple users to work concurrency, and checks for conflicts only when a save operation occurs.

How it works?

A common way to implement Optimistic Locking is by using the updatedAt, specially while developing backend solutions.

The idea is simple:

• a user opens a product - the system sends the product data along with its current updatedAt value
• the user make changes
• when the user clicks on Save, the backend compares the updatedAt value of the user, and the current updatedAt value stored in the db.
• If a match is found, it means no one else modified the data, henceforth, saves successfully. But if no match is found, a conflict is detected.

When a conflict is detected

• the update is rejected
• a collision conflict error is returned
• the user is informed, so that they can review and decide on how to proceed.

And this makes managing data and conflict more practical.

And yeah... that's about it ;)

About Me

I am Zaahra, a Google Women Techmakers Ambassador who enjoy mentoring people and writing about technical contents that might help people in their developer journey. I also enjoy building stuffs to solve real life problems.

To reach me:

LinkedIn: https://www.linkedin.com/in/faatimah-iz-zaahra-m-0670881a1/

X (previously Twitter): _fz3hra

GitHub: https://github.com/fz3hra

Cheers,

Umme Faatimah-Iz-Zaahra Mujore | Google Women TechMakers Ambassador | Software Engineer