𝐎𝐩𝐭𝐢𝐦𝐢𝐬𝐭𝐢𝐜 𝐯𝐬 𝐏𝐞𝐬𝐬𝐢𝐦𝐢𝐬𝐭𝐢𝐜 𝐋𝐨𝐜𝐤𝐢𝐧𝐠, 𝐢𝐧 𝐃𝐚𝐭𝐚𝐛𝐚𝐬𝐞𝐬

When building applications that deal with concurrent access to shared data, data consistency becomes a real challenge. Two popular approaches to handle this are Optimistic Locking and Pessimistic Locking. But they serve different purposes and come with trade-offs.

𝐎𝐩𝐭𝐢𝐦𝐢𝐬𝐭𝐢𝐜 𝐋𝐨𝐜𝐤𝐢𝐧𝐠:

𝐀𝐬𝐬𝐮𝐦𝐩𝐭𝐢𝐨𝐧: Conflicts are rare.

𝐀𝐩𝐩𝐫𝐨𝐚𝐜𝐡: Let everyone access the data, but verify before committing changes.

𝐇𝐨𝐰 𝐢𝐭 𝐰𝐨𝐫𝐤𝐬:

- A version field (e.g., version or updatedAt) is stored with the record.

- Before updating, the application checks whether the version matches.

- If not, the operation fails and must be retried.

For e.g. in SQL:

UPDATE orders SET status = 'shipped', version = version + 1 WHERE id = 101 AND version = 2;

Mongodb Example:

db.items.updateOne(
 { id: itemId, version: 3 },
 { $set: { name: "New Name" }, $inc: { version: 1 } }
)

If version has changed, the update fails indicating someone else modified it.

𝐓𝐡𝐢𝐬 𝐢𝐬 𝐔𝐬𝐞𝐝 𝐢𝐧:

- High-read, low-write systems

- APIs with stateless communication

- Systems needing scalability over strict locking

𝐏𝐞𝐬𝐬𝐢𝐦𝐢𝐬𝐭𝐢𝐜 𝐋𝐨𝐜𝐤𝐢𝐧𝐠

𝐀𝐬𝐬𝐮𝐦𝐩𝐭𝐢𝐨𝐧: Conflicts are likely.

𝐇𝐨𝐰 𝐢𝐭 𝐰𝐨𝐫𝐤𝐬:

- Lock the data to prevent others from modifying it until the lock is released.

- Other operations must wait or fail.

For e.g. in SQL

SELECT * FROM orders WHERE id = 101 FOR UPDATE;

MongoDB does not natively supports Pessimistic Locking but this can still be implemented with adding an additional lock field:

db.items.updateOne(
 { id: itemId, locked: false },
 { $set: { locked: true } }
)

Pessimistic Locks are needed in high concurrency systems such as BookMyShow or District where multiple people might attempt to book the same seat or spot.