Специалисты разобрали уязвимость Check-Then-Act, из-за которой ERP превышают лимиты

В современных корпоративных системах управления ресурсами предприятия (ERP) и автоматизированных рабочих процессах регулярно возникают проблемы, связанные с одновременной обработкой входящих данных. Когда несколько независимых запросов поступают в систему практически в один и тот же момент, архитектура распределённых приложений может дать сбой, если механизмы проверки и выполнения действий не синхронизированы на фундаментальном уровне.

Наглядно эта проблема проявляется при контроле жестких ограничений, таких как лимиты на закупку или списание товаров. К примеру, если менеджер устанавливает максимально допустимое количество в 100 единиц продукции, а в систему одновременно отправляются три независимые заявки по 40 единиц каждая, стандартный слой авторизации может одобрить каждую из них. Каждая отдельная операция выглядит допустимой, ведь 40 меньше 100, однако в сумме они дают 120 единиц, что приводит к прямому нарушению установленного регламента.

Причиной подобных инцидентов становится классический сбой паттерна Check-Then-Act в условиях конкурентного исполнения. Система сначала проверяет доступность ресурса, считает условие истинным и разрешает операцию, но зафиксировать фактические изменения в базе данных успевает только после того, как соседние потоки уже прошли аналогичную проверку. В результате каждый из параллельных процессов ориентируется на устаревшее состояние реестра и выдает разрешение без учета сопутствующих транзакций.

Для решения этой архитектурной уязвимости эксперты рекомендуют отказаться от разделения этапов проверки и применения изменений. Ответная команда на одобрение операции должна быть жестко связана с мгновенным и атомарным резервированием необходимого объёма ресурсов еще до того, как система вызовет внешний эффект или передаст данные во внешние модули. Только гарантированная блокировка лимита внутри единой базы данных позволяет избежать ситуаций с некорректным проведением операций.

Грамотное построение бизнес-логики в корпоративном софте требует проектирования транзакционных границ с учетом высоконагруженных сценариев. Разработчикам необходимо внедрять механизмы распределенных блокировок или транзакционные очереди, чтобы исключить состояние гонки данных. Подобный подход позволяет сохранить целостность корпоративных данных и защитить бизнес от непредвиденных финансово-логистических издержек, возникающих из-за технической рассинхронизации процессов.