Какую проблему мы решаем
Без контроля конкурентных изменений два пользователя или процесса могут прочитать одно состояние, независимо изменить его и перезаписать результат друг друга. Универсального решения нет: жёсткая блокировка защищает от конфликта, но заставляет остальных ждать; оптимистичный подход сохраняет параллелизм, но требует уметь обнаруживать столкновения.
Как работает решение
Pessimistic locking резервирует ресурс до завершения операции. Optimistic locking не держит долгую блокировку, а при записи проверяет версию или другой признак того, что данные не изменились с момента чтения. Если изменились, обновление отклоняется и требуется retry или новое решение. Выбор должен учитывать и UX: автоматический retry безопасен не для каждого действия.
Что получает бизнес
Бизнес получает возможность настроить баланс между throughput и строгой защитой критичных изменений. Редкие конфликты не обязаны оплачивать постоянные блокировки, а частые и дорогие столкновения могут оправдать более строгую координацию.
Что получает команда
Команда получает явную стратегию конкуренции вместо случайных lost updates. Появляются метрики конфликтов, ожидания lock и повторных попыток, по которым видно, когда выбранная модель перестала соответствовать реальной нагрузке.
Что получает клиент
Клиент получает либо контролируемое ожидание, либо понятное сообщение, что данные уже изменились и действие нужно пересмотреть, вместо тихой потери результата.
Чем мы за это платим
Pessimistic locking снижает параллелизм, создаёт ожидание и риск deadlock. Optimistic locking переносит сложность в conflict handling и UX. Неправильный выбор под ростом нагрузки превращается либо в очередь, либо в лавину retries.
Когда не нужно усложнять
Если конкурентные изменения редки, optimistic подход обычно эффективнее. Если одна сущность часто меняется одновременно и конфликт недопустим, более строгая блокировка может быть оправдана.
Что стоит спросить перед решением
- Как часто реально происходят конфликты?
- Что дороже: ожидание или повтор операции?
- Можно ли безопасно retry после конфликта?
- Как пользователь узнает, что данные изменились?
- Мониторим ли lock wait, deadlock и optimistic conflicts?
В итоге
Locking — это выбор, где заплатить за конкуренцию: заранее ожиданием или позже обработкой конфликта. Правильная стратегия защищает бизнес-результат, не покупая больше сериализации, чем нужно.