Процессинг бонусов при высокой транзакционной нагрузке

Егор Шокуров

автор:
Егор Шокуров, генеральный директор RapidSoft

время чтения:
5 минут

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

Почему бонусный процессинг становится высоконагруженной системой

Бонусный процессинг в крупных банках и сетях сталкивается с высокой нагрузкой, которая растёт вместе с бизнесом. Чем это обусловлено:

  • Большой поток карточных операций. Миллионы клиентов ежедневно совершают покупки. В пиковые периоды количество транзакций вырастает в разы, создавая серьёзную нагрузку.
  • Одновременные акции. Маркетинговые кампании запускаются совместно для разных сегментов. Это требует мгновенного применения сложных правил к каждому чеку.
  • Рост количества партнёров. Чем больше участников в программе лояльности, тем сложнее становятся правила начисления.
  • Необходимость быстро показывать бонусы клиенту. Человек хочет видеть начисленные вознаграждения сразу после покупки. Для этого нужна синхронная обработка данных с минимальной задержкой.
  • Финансовая ответственность за ошибки начисления. Любая ошибка приводит к потерям денег или недовольству клиентов.

Какие операции обрабатывает бонусный процессинг

  • Расчёт начислений — определение размера бонуса за покупку.
  • Списание бонусов — уменьшение баланса при оплате.
  • Заморозка и подтверждение — временное резервирование баллов.
  • Отмена и сторнирование — возврат бонусов при отказе от покупки.
  • Перерасчёт при возврате — корректировка.
  • Сгорание бонусов — списание баллов с истекшим сроком.
  • Ручные исправления — операции от поддержки.

Архитектурные подходы

Опишем основные варианты работы с данными.

Синхронная обработка

Клиент ждёт ответа в реальном времени (real time). Это даёт мгновенный результат, но при  перегрузках снижает производительность.

Асинхронная обработка через очереди

Запросы на начисление помещаются в очередь и обрабатываются в фоне. Это сглаживает пиковые нагрузки.

Batch-обработка

Операции обрабатываются пачками в заданные интервалы. Эффективно для перерасчётов и сверок.

Гибридная модель

Быстрый предварительный расчёт выполняется синхронно, а финальная сверка — асинхронно batch-процессами.

Event-driven архитектура

Система реагирует на события, генерируя цепочки обработки через очереди сообщений.

Как проектировать обработку транзакций

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

  • Уникальный идентификатор. Каждая операция должна получать уникальный ID от источника. Это основа для всех механизмов контроля.
  • Статусы жизненного цикла. Операция может быть в состоянии: «Получена», «В очереди», «В обработке», «Завершена», «Ошибка».
  • Защита от повторной обработки. Идемпотентность гарантирует, что повторная обработка не приведёт к двойному начислению.
  • Ретраи при временных ошибках. При недоступности внешних систем попытки совершить операцию автоматически повторяются.
  • Dead letter queue для проблемных операций. Они после нескольких ретраев помещаются в специальную очередь.
  • Приоритеты обработки. Выполнение важных операций — первостепенно.

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

Как обеспечить скорость и стабильность

  • Горизонтальное масштабирование — добавление новых обработчиков: воркеров / консьюмеров / подов.
  • Разделение потоков начисления и списания — операции разных типов не мешают друг другу.
  • Кеширование правил программы — условия хранятся в быстром кеше.
  • Предрасчёт категорий и сегментов — категории вычисляются заранее.
  • Оптимизация запросов к бонусной базе данных — минимизация обращений.
  • Ограничение тяжёлых расчётов — сложные правила выносятся в асинхронный контур.

Похожие принципы масштабирования применяются и при интеграции бонусного контура с биллингом мобильного оператора.

Как работать с правилами начисления под нагрузкой

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

Простые правила для online-расчёта

Для синхронной обработки в реальном времени используются простые правила: например, «1 % кешбэка за любую покупку».

Сложные условия в отложенной обработке

Многоступенчатые правила выполняются в batch-режиме или через очередь.

Версионирование правил

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

Проверка лимитов и исключений

Каждая операция проверяется на превышение лимитов и исключения.

Разделение настройки и исполнения

Маркетологи настраивают правила, техническая система исполняет их.

Как избежать потери и дублей бонусных операций

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

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

Нагрузочное тестирование

Чтобы убедиться, что система выдержит пиковые нагрузки, проверяют пять сценариев: эмуляцию потока транзакций, пиковые периоды (например, «Чёрную пятницу»), повторную обработку накопившихся очередей, отказы внешних систем и время ответа API.

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

Какие метрики мониторить

  • Количество операций в секунду — пропускная способность системы.
  • Время расчёта бонусов — важно для пользовательского опыта.
  • Длина очередей — рост указывает на нехватку воркеров.
  • Доля ошибочных операций — процент транзакций с ошибкой.
  • Количество повторных обработок — число операций после ретрая.
  • Расхождение балансов после сверки — метрика точности.

Технические метрики стоит дополнять и бизнес-показателями эффективности программы лояльности в целом.

FAQ: процессинг бонусов при высокой нагрузке

Что такое бонусный процессинг?

Это система, которая рассчитывает, начисляет, списывает и хранит информацию о бонусах и кешбэке.

Что такое идемпотентность?

Это гарантия, что повторная обработка не приведёт к двойному начислению бонусов.

В чём разница между синхронной и асинхронной обработкой?

Синхронная даёт ответ сразу, асинхронная — сглаживает пики через очереди.

Запрос
на консультацию
Расскажем об автоматизации программы лояльности, покажем маркетинговые механики в деле, подберём решение под ваши задачи
Оставить заявку
Имидж Обсудить проект
Поделиться:
Как программа лояльности помогает ритейлу удержать клиента от ухода к маркетплейсам
Покупатель выходит из магазина с полным пакетом и хорошим настроением: продавец помог подобрать размер, на кассе не было очереди, и модная куртка была успешно приобретена. По всем меркам удачный визит, из тех, что обычно и формируют лояльность к бренду. А через месяц тот же человек заказывает ботинки уже на маркетплейсе, и даже не вспоминает про магазин, где так удачно прошла покупка в прошлый раз.
Читать полностью
Архитектура масштабируемой системы лояльности для крупного банка
Масштабируемая система лояльности — это отдельный сервисный контур с процессингом, API, модулем правил, антифродом и другими компонентами. Такая архитектура включает всё необходимое для обработки миллионов транзакций и управления десятками программ без риска для бизнеса. Зачем она нужна крупному банку, как её выстроить и из чего она состоит, рассказываем в статье.
Читать полностью