Один свободный лимит, две заявки: как распределяется ёмкость трейдера

Разберём условную гонку запросов. В 14:00:00 два потока обработки прочитали один и тот же свободный остаток: 12 000. Каждый получил заявку на 8 000, проверил условие «денег достаточно» и выдал клиенту реквизиты. По отдельности оба решения выглядели правильными. Вместе они создали обязательства на 16 000 при доступной ёмкости 12 000.

Это не обязательно мошенничество трейдера или задержка банковского баланса. Достаточно разнести проверку остатка и его резервирование на две независимые операции. Внешне система будет работать нормально до момента, когда заявки придут достаточно близко друг к другу. На P2P-потоке такую ошибку усиливает время между выдачей реквизитов, фактическим переводом и подтверждением получения.

Ёмкость состоит из нескольких ограничений

У заявки есть сумма, валюта, платёжный метод и срок исполнения. У трейдера есть доступное обеспечение либо рабочий расчётный баланс, разрешённые счета, лимит одновременных заявок и операционная доступность. У конкретного счёта действуют собственные допустимые суммы, ограничения банка и уже занятый объём. У оператора могут быть дополнительные договорные пределы на участника и всю группу связанных исполнителей.

Ни один из этих параметров не заменяет остальные. Большой депозит не разрешает превысить банковский лимит. Свободный банковский остаток не означает, что предоплаченного расчётного баланса хватит для признания нового приёма. Возможность обработать ещё одну заявку по счётчику не помогает, если единственный доступный канал не поддерживает её валюту.

Для одной однородной категории операций денежная ёмкость ограничивается самым тесным денежным ограничением. Но счётчик параллельных заявок и допустимый диапазон суммы остаются отдельными условиями. Нельзя просто сложить остатки разных валют или считать, что два свободных слота автоматически вмещают два платежа любого размера. Период каждого лимита также задаётся явно: календарный день, скользящее окно, смена или весь срок договора.

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

Решение должно занять ресурс в тот же момент

В примере с 12 000 первая заявка на 8 000 получает бронь, после которой доступно 4 000. Вторая проверяется уже относительно нового состояния и не проходит. Смысл атомарного резервирования именно в этом: проверка и изменение состояния фиксируются как одно неделимое решение. Его результат включает идентификатор брони, сумму, владельца и срок действия.

Платёжные реестры реализуют такую защиту разными способами. Документация Modern Treasury, например, описывает запись с условием на итоговый баланс или версию счёта. PostgreSQL предоставляет блокировки строк для управления конкурирующими изменениями. Это технические механизмы, а не готовая P2P-политика: команда ещё должна определить, какие ресурсы меняются совместно и при каком событии бронь освобождается.

Если назначение одновременно занимает баланс трейдера, остаток по счёту и один слот, частичное выполнение опасно. Записали бронь денег, но потеряли назначение: лимит завис. Создали заявку, но не уменьшили остаток: возникла переаллокация. В пределах одной согласованной транзакции эти изменения либо происходят вместе, либо не происходят. При нескольких системах нужен явный промежуточный статус и восстановление, которое не выдаёт реквизиты до подтверждения необходимых резервов.

Повтор запроса не должен съедать второй кусок

Мерчант не получил ответ и повторил создание. Если логический заказ прежний, оператор должен найти существующую бронь или безопасно завершить её создание. Новый сетевой запрос сам по себе не оправдывает новую заявку у того же трейдера. Иначе один покупатель займёт несколько слотов и получит несколько комплектов реквизитов, хотя собирался заплатить один раз.

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

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

Освободили слот, но риск остался

Представим, заявка истекла в 14:10, бронь сняли, а в 14:12 обнаружили банковское поступление. Запись денег не исчезает из-за отсутствия свободного лимита. Она переходит в исключение: подтверждаются источник и назначение, определяется обязательство и восстанавливается корректное распределение риска. До решения может потребоваться остановить новые назначения этому участнику.

Неверный выход состоит в том, чтобы считать поздние деньги доходом оператора или автоматически привязать их к следующей заявке с такой же суммой. Корректный выход сохраняет связь с первоначальной выдачей реквизитов. Если предусмотрено отдельное окно для поздних поступлений, его стоимость включают в модель занятости заранее. Иначе «оптимизация» быстрого освобождения лимита просто прячет риск в ручной очереди.

Депозит даёт запас, скорость даёт оборот

Рассчитаем условную пропускную способность. Есть 300 000 пригодного обеспечения, типовая заявка на 10 000 и 12 параллельных операционных слотов. На обработку заявки до подтверждения уходит в среднем восемь минут. Ограничение слотов допускает теоретически 90 назначений в час: 12 умножить на 60 и разделить на восемь. При одинаковой сумме это 900 000 часового потока до прочих ограничений.

Однако по договору обеспечение удерживается до расчёта, в среднем 40 минут. Тогда 300 000 покрытия при непрерывной загрузке поддерживают примерно 450 000 оборота в час: 300 000 умножить на 60 и разделить на 40. Операционные слоты могли бы принять больше, но обеспечение возвращается медленнее. Это оценка для устойчивого равномерного потока, а не обещание производительности.

Если остаток допустимого дневного объёма банковского канала составляет 1 200 000, даже этот темп исчерпает его примерно за два часа сорок минут. Увеличение депозита не изменит банковский предел. А при росте времени расчёта до 80 минут залоговое ограничение снизит оценку до 225 000 в час, хотя число подключённых трейдеров останется прежним.

Что нужно видеть на рабочем экране

Полезный экран ёмкости объясняет отказы: не хватает обеспечения, рабочего баланса, исходящей ликвидности, разрешённого объёма канала, свободного слота или подтверждённой доступности участника. Рядом видны возраст резервов и время фактического освобождения. Общее «нет реквизитов» скрывает причины, которые требуют совершенно разных решений.

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