Optimistic vs Pessimistic Concurrency Revisited
When many clients update the same record, you must decide how to prevent two writes from clobbering each other. There are two broad strategies.
Pessimistic concurrency assumes conflicts are likely. A client takes a lock before reading, holds it while computing, and releases it after writing. While the lock is held nobody else can touch the row. This is simple to reason about but it serializes work and a slow or crashed holder blocks everyone behind it.
Optimistic concurrency assumes conflicts are rare. A client reads a record plus a version number, computes freely with no lock, then writes only if the version still matches. If another writer slipped in first, the version moved and the write is rejected, so the client retries with fresh data.
- Pessimistic trades throughput for certainty, good for high contention and long critical sections.
- Optimistic trades occasional retries for high parallelism, good for low contention and short transactions.
Most web applications lean optimistic because reads vastly outnumber conflicting writes, and locks held across user think time are dangerous.
Key idea
Pessimistic locking blocks others up front, while optimistic checking lets work proceed and only rejects writes when a version conflict is detected.