Lock Now or Check Later: Optimistic vs. Pessimistic Concurrency

WHY IT EXISTS: Concurrency control exists to prevent data corruption when multiple operations try to change the same piece of data at the same time. Without it, you get race conditions, like two ATM withdrawals on the same account leading to an incorrect final balance.

THE MENTAL MODEL: Think of it as asking for permission versus asking for forgiveness. Pessimistic control is like a cautious person who calls to reserve a conference room before even planning the meeting (asking for permission). It assumes someone else wants it. Optimistic control is like a bold person who just walks into an empty room, holds the meeting, and only checks for a reservation conflict on the way out (asking for forgiveness). It assumes the room is free.

HOW IT WORKS: Pessimistic control uses locks. A transaction wanting to modify data must first acquire a lock. Other transactions are blocked from accessing that data until the lock is released. This is often implemented with database commands like SELECT ... FOR UPDATE. Optimistic control, by contrast, uses versioning. A transaction reads data and notes its version number or timestamp. It then does its work. Before committing, it checks if the data's version has changed. If it hasn't, the commit succeeds. If it has, the transaction is aborted and must be retried from the beginning.

WHEN TO USE IT: Use pessimistic control in high-contention systems where conflicts are frequent and the cost of retrying a transaction is high, such as in financial systems or inventory management for popular items. Use optimistic control in low-contention, read-heavy systems where conflicts are rare. This is common in content management systems or wikis, where the odds of two users editing the exact same sentence at the same time are low.

WHEN NOT TO USE IT: Avoid pessimistic control in low-contention environments; the overhead of managing locks creates unnecessary bottlenecks and can lead to deadlocks. Avoid optimistic control in high-contention environments; the constant transaction rollbacks and retries will waste significant resources and can lead to some transactions never succeeding (a state called starvation).

ONE CANONICAL EXAMPLE: For pessimistic locking, imagine booking the last seat on a flight. The first user's transaction locks the seat's record in the database. When a second user tries to book it, their request is blocked until the first user completes their purchase and the lock is released. For optimistic locking, consider two admins editing a blog post. Admin A loads the post (version 5). Admin B loads the same post (version 5). Admin A saves her changes, updating the post to version 6. When Admin B tries to save his changes, the system sees he started with version 5 but the current version is 6, indicating a conflict. It rejects his save and requires him to reload the post to merge his changes.