Оптимистичная блокировка - подход, при котором мы не блокируем данные, а просто проверяем, не изменил ли их кто-то другой перед сохранением.

Простая аналогия, представьте, что работаете с Git:
1. Вы создаёте ветку → делаете коммиты → нажимаете git push
2. А кто-то другой уже запушил изменения в main
3. Git говорит: «Конфликт! Сделайте pull и смержите»
4. Вы подтягиваете изменения, разрешаете конфликт → пушите снова ✅

Как это работает в БД:

-- 1. Читаем данные + версию
SELECT balance, version FROM accounts WHERE id = 123;
-- Получаем: balance=100, version=5

-- 2. Меняем у себя в коде
new_balance = 150
new_version = 6

-- 3. Пытаемся сохранить с проверкой версии
UPDATE accounts
SET balance = 150, version = 6
WHERE id = 123 AND version = 5;

-- Если обновлено 0 строк → КОНФЛИКТ! Начинаем с начала
-- Кто-то уже сохранил version=6

Когда применимо:
- Ожидаются редкие конфликты
- Пользователь думает минуты между чтением и сохранением
- Можно откатить транзакцию и начать заново
- Изменяется ограниченный набор строк

Мораль:
Блокировка данных — это дорого.
Конфликт версий — это дёшево.
Оптимистичная блокировка выбирает дешёвый путь, пока он работает.