What is the difference between optimistic and pessimistic locking in distributed systems?

Pessimistic locking assumes conflicts will happen — acquires locks before reading or modifying data, preventing others from touching the data until done. Implemented via: row-level locks (SELECT FOR UPDATE in SQL), distributed locks (Redis SETNX, ZooKeeper ephemeral nodes, etcd). Pros: prevents conflicts entirely, simple application logic (just hold the lock). Cons: reduces concurrency, risk of deadlocks (multiple processes waiting for each other's locks), distributed lock failures (lock holder crashes, lease must expire before lock is released — adds latency). Good for: high contention scenarios, when conflicts are expected, when operations are long and re-doing them is expensive. Optimistic locking assumes conflicts are rare — reads data and remembers a version (version number, timestamp, ETag, or checksum). When writing back, checks if version matches — if someone else has changed it since the read, abort and retry. Implemented via: version column in SQL (UPDATE ... WHERE id=X AND version=Y), HTTP ETags (If-Match header), CAS (Compare-And-Swap) in Redis. Pros: high concurrency (no locks held during read-think-write cycle), no deadlocks, better for read-heavy workloads. Cons: optimistic concurrency conflicts require retry logic, can cause starvation under high contention (always retrying). Good for: low contention, read-heavy, short operations. Distributed lock implementations: Redis RedLock (controversial, uses multiple Redis masters), ZooKeeper ephemeral znodes (strong consistency), etcd leases (Raft-backed, highly reliable). Lease-based locks: lock expires automatically if holder crashes — prevents stale locks.