Comparisons
Ten pairs that get conflated in real conversations. Neither column wins — what decides is the requirement. Each record leads with the confusion, because the confusion is the reason the record exists.
Authentication vs AuthorizationServer sessions vs TokensORM vs Raw SQLOptimistic vs Pessimistic concurrencySynchronous vs Asynchronous communicationOffset vs Cursor paginationLocal (in-process) vs Distributed cacheMonolith vs MicroservicesHorizontal vs Vertical scalingAt-least-once vs "Exactly-once"
Optimistic vs Pessimistic concurrency
What people get wrong about this pair
Optimistic is read as "no locking" — but the database still takes locks during the update; what you avoided is holding one across the user's thinking time. And the version check is worthless unless the update is conditional on the version in the same statement.
Optimistic (version check on write)
Use it when
Low contention: conflicts are rare, and a retry or a "someone else changed this" message is acceptable.
Pessimistic (lock the row first)
Use it when
High contention on a hot row, or a sequence of reads and writes that must not interleave at all.
| Dimension | Optimistic (version check on write) | Pessimistic (lock the row first) |
|---|---|---|
| Conflict detected | At write time | Prevented at read time |
| Held resource | Nothing between read and write | A row lock, and the connection holding it |
| Cost under contention | Wasted work and retries | Waiting, and a deadlock risk from lock ordering |
| User experience | May be told to retry | Waits, or times out acquiring |
| Works across requests | Yes — version travels with the payload | Only within one transaction |
| Watch out for | Retry loops that never converge on a hot row | Locks held while calling a third party |