Optimistic concurrency control bets that conflicts are rare and retries are cheap. Pessimistic concurrency control makes the opposite bet: it assumes conflicts are likely or that retrying is catastrophically expensive, so it acquires a lock before touching the data and holds it until the transaction commits. Other transactions wait. No CAS gymnastics, no retry storms — just an old-fashioned queue.

The trade-off is brutal but honest. You give up throughput and concurrency in exchange for predictability. A transaction that grabs the lock will either succeed or deadlock — it will never do five seconds of work only to be told "someone else got there first, start over."

When pessimistic wins:

• High contention. If 80% of transactions touch the same row, optimistic retries will thrash. Locking serializes them cleanly.
• Long or expensive transactions. Recomputing a 10-second report after a conflict is worse than waiting 10 seconds for a lock.
• Side effects mid-transaction. If your transaction sends an email or charges a card before commit, you cannot safely retry.
• Hard external invariants. Seat booking, inventory decrement, financial ledger entries — anywhere "looked fine when I checked" isn't good enough.

Real-world example: An airline seat-booking service. Two agents try to sell seat 14C at the same time. With optimistic control, both read "available," both write "sold," and the version check rejects one — but only after the customer's card was authorized. With SELECT ... FOR UPDATE, the first agent's transaction locks row 14C; the second blocks until the first commits, then re-reads and sees "sold." No double-booking, no refund flow, no apology email.

Rule of thumb: If your retry rate under optimistic control exceeds ~10–15%, switch to pessimistic. Below that, the lock overhead and reduced concurrency cost more than the occasional retry. Measure conflict rate in production before choosing — most teams pick a strategy by reflex and pay for it later.

The pitfalls are real:

• Deadlocks. Always acquire locks in a consistent order (e.g., by primary key ascending). Set a lock timeout — never wait forever.
• Lock duration. Hold locks for the shortest possible window. Do all reads and computation before the locked section if you can.
• No long-running user think time inside the lock. Locking a row while a user fills out a form is how you destroy throughput. Use a soft application-level reservation with a TTL instead.
• Lock escalation. Some databases promote row locks to table locks under pressure. Know your engine's behavior.