1. Введение

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

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

Практика использования idempotency key показывает, что безопасный повтор запроса после сбоя связи является обязательным элементом современных API [1], [2]. Однако этот механизм решает только часть проблемы, поскольку распределённая система содержит не один, а несколько уровней повторов: сетевой, интеграционный, прикладной и бизнес-уровень. Для асинхронного обмена характерна семантика at-least-once delivery, при которой обработчик обязан корректно воспринимать повторную доставку сообщения [3], [4].

Объектом исследования являются процессы обработки кредитных операций в распределённых информационных системах. Предметом исследования выступают методы обеспечения идемпотентности и их способность предотвращать повторную обработку запросов, сообщений и доменных переходов состояния. Цель статьи — сравнить методы обеспечения идемпотентности в кредитных информационных системах и определить условия их рационального сочетания. Для достижения цели решаются следующие задачи: раскрыть специфику повторной обработки операций в кредитном домене; выделить уровни идемпотентности в распределённой архитектуре; сравнить подходы на основе idempotency key, бизнес-ключа операции и контроля состояния бизнес-объекта; выполнить многокритериальную оценку методов; проверить устойчивость выводов с помощью анализа чувствительности и модельного эксперимента. Научная новизна работы состоит в разделении уровней идемпотентности, введении критерия повторного бизнес-эффекта и дополнении экспертной модели результатами имитационной проверки. Практическая значимость заключается в формировании рекомендаций для проектирования кредитных сервисов, в которых недопустимо повторное выполнение финансово значимой операции.

2. Методы и принципы исследования

2.1. Теоретические основания идемпотентности в распределённых кредитных системах

В классическом понимании операция является идемпотентной, если её повторное выполнение не изменяет результат сверх первого применения. Для HTTP это означает, что несколько одинаковых запросов должны приводить к тому же наблюдаемому состоянию ресурса, что и один запрос [5]. В прикладных финансовых системах такое определение требует расширения, поскольку одинаковость запроса и одинаковость бизнес-операции не совпадают.

Теоретически команду можно представить как пару [LATEX_FORMULA]c = (a, p)[/LATEX_FORMULA], где [LATEX_FORMULA]a[/LATEX_FORMULA] тип действия, а [LATEX_FORMULA]p[/LATEX_FORMULA] набор параметров. Состояние доменного объекта обозначим через [LATEX_FORMULA]s[/LATEX_FORMULA], а переход состояния через функцию [LATEX_FORMULA]\delta(\mathrm{s}, \mathrm{c}) .[/LATEX_FORMULA]. На уровне бизнес-эффекта требуется, чтобы для повторной или эквивалентной команды c' выполнялось условие [LATEX_FORMULA]\delta\left(\delta(s, c), c^{\prime}\right)=\delta(s, c)[/LATEX_FORMULA]. Иными словами, второй вызов не должен создавать новый финансовый результат, если первый уже сформировал требуемое состояние.

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

Распределённые транзакции усложняют применение этого правила. В микросервисной архитектуре данные кредитной заявки, расчёта лимита, договора и уведомлений могут находиться в разных сервисах. Глобальная атомарность часто заменяется локальными транзакциями, обменом событиями и компенсационными действиями [6]. Поэтому в практическом проектировании более корректно говорить не об exactly-once delivery, а об exactly-once effect: сообщение может быть получено несколько раз, но бизнес-эффект должен быть зафиксирован однократно.

С теоретической точки зрения идемпотентность опирается на инварианты предметной области. Инвариант кредитной заявки может запрещать повторную регистрацию активной заявки с тем же внешним номером; инвариант договора повторную активацию уже активированного договора; инвариант лимита повторное резервирование одной и той же суммы по одной операции. Такие правила ближе к доменной модели, чем к транспортному протоколу, и требуют проектирования конечного автомата состояний [7], [8].

2.2. Источники повторов и модель риска

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

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

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

2.3. Методы обеспечения идемпотентности

Для сравнительного анализа выделены три базовых метода: idempotency key, бизнес-ключ операции и контроль состояния с учётом ожидаемого бизнес-эффекта.

Метод idempotency key основан на сохранении уникального идентификатора запроса вместе с результатом его обработки. Если запрос с таким ключом уже обрабатывался, система не выполняет операцию повторно, а возвращает ранее зафиксированный результат [1]. Этот подход удобен для синхронных API-вызовов и позволяет выявлять дубликат до выполнения основной бизнес-логики [2]. Недостаток метода состоит в том, что защита зависит от генерации, передачи и хранения ключа [9]. Ограничение проявляется в межканальных сценариях: новая техническая команда может иметь другой ключ, но соответствовать уже обработанной кредитной операции.

Бизнес-ключ операции строится из доменных атрибутов, позволяющих идентифицировать смысл операции. Для кредитной заявки таким ключом могут быть идентификатор клиента, продукт, внешний номер заявки, канал-партнёр, сумма, валюта и дата операционного окна. В отличие от технического ключа, бизнес-ключ устойчив к изменению транспорта и помогает распознавать дубликаты, пришедшие из мобильного приложения, веб-интерфейса, операторского контура или партнёрской системы [10], [11]. Основной риск бизнес-ключа связан с выбором состава атрибутов. Слишком узкий ключ пропускает реальные дубли, поскольку разные сообщения не будут сопоставлены. Слишком широкий ключ приводит к ложной блокировке допустимых операций: например, клиент действительно подал две похожие заявки в разные моменты времени. Поэтому бизнес-ключ должен проектироваться как часть предметной модели, а не как произвольный технический индекс.

Контроль состояния и ожидаемого бизнес-эффекта использует конечный автомат объекта. Он основан на контроле состояния бизнес-объекта и ожидаемого бизнес-эффекта. Повторная обработка не допускается, если система уже достигла нужного результата. Такой метод ближе всего к доменным инвариантам: он проверяет не совпадение сообщений, а допустимость перехода состояния. Преимущество этого метода в том, что он тесно связан с бизнес-логикой, но для него нужно иметь чёткую модель состояний и правил перехода между ними [7]. Недостаток контроля состояния состоит в большей сложности внедрения. Требуется формальная модель состояний, перечень допустимых переходов, правила обработки конкурентных команд и защита от гонок на уровне транзакций или версий объекта.

2.4. Методика сравнительной оценки

Сравнение методов выполнено по шести критериям: C1 точность выявления дублей; C2 устойчивость к межканальным повторам; C3 сложность внедрения; C4 независимость от предметной логики; C5 надёжность предотвращения повторного бизнес-эффекта; C6 удобство сопровождения. Оценка каждого метода задаётся по шкале от 1 до 5, где 1 означает низкое соответствие критерию, а 5 высокое.

Интегральная оценка метода определяется как взвешенная сумма частных оценок:

Здесь [LATEX_FORMULA]I(m)[/LATEX_FORMULA] итоговая оценка метода [LATEX_FORMULA]m[/LATEX_FORMULA], [LATEX_FORMULA]w_{i}[/LATEX_FORMULA] вес критерия [LATEX_FORMULA]i[/LATEX_FORMULA], [LATEX_FORMULA]x_{m i}[/LATEX_FORMULA] экспертная оценка метода по критерию. Веса заданы с учётом риска кредитного процесса: наибольший вес получает C5, поскольку именно повторный бизнес-эффект напрямую влияет на финансовую корректность операции. Критерии C3, C4 и C6 отражают эксплуатационные свойства и имеют меньшую значимость, чем предотвращение ошибочного результата. Веса и обоснования представлены в таблице 1.

Представленные в таблице 1 критерии и весовые коэффициенты используются далее для расчёта интегральной оценки каждого метода обеспечения идемпотентности.

Для метода idempotency key интегральная оценка рассчитывается следующим образом:

Для метода бизнес-ключа операции:

Для метода контроля состояния и ожидаемого бизнес-эффекта:

Результаты сравнительной оценки представлены в таблице 2.

Разница не означает неэффективность технического ключа; она показывает, что один уровень защиты не закрывает все классы повторов.

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

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

Эмпирическая проверка на модельном наборе данных

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

Каждое событие содержало технический идентификатор запроса, канал поступления, бизнес-атрибуты операции, состояние объекта до обработки и признак допустимости новой операции.

где

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

На основе сформированного модельного журнала была выполнена сравнительная проверка методов. Для каждого подхода рассчитаны значения метрик. Дополнительно зафиксировано количество случаев, в которых повторная обработка приводила к повторному бизнес-эффекту. Результаты проверки представлены в таблице 5.

Результаты показывают, что idempotency key почти не создаёт ложных блокировок, но обнаруживает только 48,0% дублей, так как межканальные и событийные повторы имеют другие технические параметры. Бизнес-ключ повышает полноту до 81,4%, однако увеличивает число FP: часть допустимых похожих операций ошибочно классифицируется как повтор. Контроль состояния достигает recall 89,9% и резко снижает число повторных бизнес-эффектов, потому что решение принимается по доменному состоянию, а не только по признакам входного сообщения.

Наилучший результат показала комбинированная схема. Она не заменяет три базовых метода, а последовательно применяет их: сначала проверяется idempotency key, затем бизнес-ключ, после чего выполняется контроль допустимости перехода состояния. В модельном журнале такая схема оставила 4 случая повторного бизнес-эффекта против 413 у одного idempotency key. Это подтверждает тезис о необходимости многоуровневой защиты в кредитных информационных системах.

3. Основные результаты

Полученные результаты позволяют уточнить архитектурные рекомендации. Idempotency key следует применять на границе внешнего API, где он устраняет повторные запросы клиента и снижает нагрузку на логику. Запись о ключе должна сохраняться атомарно с результатом обработки либо в рамках транзакции, либо через согласованный журнал состояния запроса.

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

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

Практически наиболее устойчивой является схема «технический ключ + бизнес-ключ + состояние». Технический ключ защищает от потери ответа и повторного нажатия кнопки. Бизнес-ключ выявляет дубли, пришедшие по разным каналам. Контроль состояния предотвращает ошибочный результат в ситуациях, когда два первых уровня не дали полной уверенности. Такая комбинация снижает зависимость от одного механизма и повышает объяснимость решения при аудите.

4. Заключение

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

Многокритериальная оценка показала наибольшую интегральную эффективность контроля состояния и ожидаемого бизнес-эффекта. Бизнес-ключ операции оказался наиболее полезен для межканальных повторов, а idempotency key для ранней обработки повторных API-вызовов. Анализ чувствительности подтвердил, что при изменении весов меняется относительный отрыв методов, но сохраняется вывод о необходимости их сочетания.

Эмпирическая проверка на модельном журнале из 11 450 событий дополнила экспертные выводы количественными данными. Одиночный idempotency key выявил 48,0% дублей, бизнес-ключ 81,4%, контроль состояния 89,9%, а комбинированная схема 99,1%. Число остаточных повторных бизнес-эффектов снизилось с 413 при использовании только idempotency key до 4 при многоуровневой защите.

Для кредитных информационных систем рекомендуется комбинированный подход: на входе API использовать idempotency key, в прикладной логике применять бизнес-ключ операции, а в доменной модели контролировать допустимость перехода состояния. Дальнейшее развитие исследования может быть связано с проверкой модели на промышленных данных, оценкой стоимости ложных блокировок и разработкой адаптивных правил бизнес-ключа для разных кредитных продуктов.

The additional file for this article can be found as follows: