Pessimistic Locking
Assume conflicts are likely: lock the row up front so no one else can touch it until you are done.
Pessimistic locking assumes conflicts are likely, so it acquires a lock on the data before working (for example SELECT … FOR UPDATE) and holds it until the transaction commits — no one else can modify the locked rows meanwhile. It guarantees no lost updates at the cost of concurrency.
Worked example: booking the last seat, you SELECT the seat FOR UPDATE so a second buyer blocks until you commit or roll back — no double-booking possible. Gotcha: holding locks reduces throughput and invites deadlocks (two transactions locking in different orders), and a client that grabs a lock then stalls blocks everyone — which is why pessimistic locks should be held briefly and paired with timeouts; under low contention, optimistic locking is usually faster.