Движок рабочих процессов

1) Зачем нужен движок

• Предсказуемыми: явные шаги, статусы, SLA и ответственные.
• Надежными: идемпотентность, ретраи, компенсации, дедлайны.
• Прозрачными: метрики, трассировка, аудит, доказуемость для регуляторов.
• Эффективными: автоматизация рутины + человек подключается по правилам.

2) Ключевые принципы

Orchestrate the critical, choreograph the rest: критичные цепочки (платежи/выводы/сеттл) — под централизованной оркестрацией; некритичные события — через хореографию (pub/sub).
Идемпотентность везде: каждый шаг принимает `idempotency_key` и хранит результаты.
SLA-осознанность: время на шаг и общий дедлайн фиксированы; эскалации по таймерам.
Compensate, don’t rollback DB: для внешних эффектов — саги/компенсации.
Human-in-the-loop: формализованные “узкие ворота” (аппрувы, 4-eyes, SoD).
Policy-as-Code: маршрутизация, приоритеты, условия ветвлений — в политиках.
Наблюдаемость: каждое задание имеет SLI/SLO, трейсы и аудит.

3) Модель предметной области

3.1 Базовые сущности

Process (Процесс): долгоживущая оркестрация (минуты/часы/дни).
Task (Задача): атомарная операция (сервисная/человеческая).
Activity (Активность): шаг процесса с типом (service/human/decision).
Signal/Event: внешние события (PSP-вебхук, KYC-ответ, пользовательское действие).
Timer: дедлайны, напоминания, периодика.
Context: безопасный payload процесса (тенант, регион, KYC-ид, лимиты, риск-скор).

3.2 Состояния задач

`scheduled → running → (succeeded | failed | timed_out | cancelled | compensated)`

4) Архитектурные паттерны

Оркестратор процессов: центральный движок хранит состояние, таймеры, очереди, маршрутизацию.
Выполнители (workers): статeless-сервисы, подписанные на очереди задач доменов (Payments, KYC, Risk, Games).
Саги: для каждой “сильной” операции есть обратная (компенсационная).
Outbox/Inbox: гарантии “exactly-once” интеграции с внешними системами.
Command/Callback: задачи инициируются командами; результаты — по колбэкам/вебхукам.
Feature flags: динамический выбор веток (например, альтернативный PSP).
Трассировка: корелляция `trace_id` процесса со всеми вызовами.

5) Гарантии и устойчивость

At-least-once исполнение задач + идемпотентность обработчиков.
Ретраи с джиттером и ограниченными бюджетами (per-task, per-process).
Тайм-ауты: `task_timeout` < SLA шага; `process_deadline` < регуляторного срока.
Гистерезис и backoff: защита от штормов.
Circuit-breakers: останов ретраев при “красном” состоянии зависимости.
Дед-леттер (DLQ): для ручной разборки редких сбоев с полным контекстом.

6) Каталог типовых процессов (iGaming)

1. Депозит: init → 3DS/auth → capture → ledger → бонус-кредиты → уведомление → антифрод-проверка (асинхронно).

Компенсации: отмена/cancel, сторно, возврат бонуса.

2. Вывод средств: запрос → скоринг риска → 4-eyes аппрув → платежный шлюз → реестр выплат → уведомление.

Компенсации: отмена вывода, повторный маршрут, freeze аккаунта.
3. KYC/AML: сбор документов → провайдер 1 → fallback провайдер 2 → ручная проверка → результат/TTL.
4. Ставка/сеттл: резервация → фиксация коэффициента → подтверждение → сеттл/расчет → выплата.
5. Бонусная кампания: таргетинг → выпуск купонов → активация → мониторинг бюджета → экспирация/отмена.
6. Инцидент-процесс: детект → классификация P1–P4 → вар-рум → действия → закрытие → пост-мортем.

7) Конструкция шага (Task Spec)

Идемпотентный ключ: `task_id` + бизнес-ключ (например, `withdrawal_id`).
Предусловия: условия запуска (данные, лимиты, флаги).
Действие: RPC/HTTP/gRPC/команда очереди.
Обработка результата: успешный/частичный/ошибка/тайм-аут.
Ретраи: стратегия (exp backoff + jitter), максимум попыток.
Компенсация: обратное действие/переход в безопасное состояние.
Аудит: что, кем/чем, когда и зачем; до/после.

8) Human-in-the-loop

Встроенные human-tasks: чек-лист, вложения, подсказки (runbook), RACI.
SoD/4-eyes: несовместимые роли, два аппрувера для P1/P2.
SLA: эскалации при бездействии (таймеры, смена группы, авто-decline/approve в low-risk).
Коммуникация: уведомления в нужные каналы, статус-страница по P1/P2 через Comms Lead.

9) SLA, приоритизация и планировщик

Приоритеты: P1 (немедленно) → P2 → P3 (фоновое).
Квоты: per-тенант/регион/провайдер; защита от “захвата” очереди.
Дедлайны: на шаг и процесс; пропуск дедлайна → компенсации/эскалации.
Периодика: cron-процессы (закрытие реестров, экспирация бонусов, отчеты регуляторам).
Очереди по классам QoS: реальное время (A), операционные (B), аналитические (C).

10) Политики и DSL

Policy-as-Code: Rego/YAML/JSON-DSL для ветвлений, маршрутизации PSP, требований SoD, лимитов.
Версионирование: миграция процессов v1→v2 без прерывания активных инстансов.
Canary-политики: часть трафика по новой ветке; rollback по SLI.

11) Данные, приватность и комплаенс

Минимизация контекста: в процессе — только нужные поля; PII — токенизирована.
Geo-aware хранение: по юрисдикциям (GDPR и локальные правила).
TTL и ретеншн: разные для журналов, артефактов и документов.
Экспорт: только по workflow с шифрованием, тикетом и SoD.
Аудит: неподменяемые логи (WORM), связность событий.

12) Наблюдаемость и контроль качества

SLI/SLO процесса: доля завершений, средняя/95-я длительность, нарушения SLA.
Метрики задач: успех/ошибка/ретраи/тайм-ауты, возраст в очереди.
Трейсы: спаны по шагам, корреляция с платежами/игровыми событиями.
Дашборды: Exec (SLA/бюджет ошибок, узкие места), Ops (очереди/лаг, ретраи, DLQ), Risk/Payments (PSP-ветки, аппрувы).
Аномалии: STL/CUSUM/CPD на длительности и ошибках; авто-скейл/фейловер.

13) Стоимость (FinOps Workflow)

$/инстанс процесса, $/задачу, $/ретрай.
Оптимизации: батчинг низкоприоритетных шагов, агрегация событий, лимиты на длинные процессы, очистка старых данных.
Квоты: на запуск/хранение per-тенант; showback/chargeback.

14) Безопасность

IAM/ABAC: доступ к процессам/задачам по ролям и атрибутам (тенант/регион/окружение).
PAM/JIT: временные привилегии для ручных шагов.
Подпись вебхуков и запросов: HMAC/мТLS.
Защитные действия: авто-блок экспорта PII при аномалии; dual control на чувствительные ветки (PSP-роутинг, лимиты выплат).

15) Интеграции

Платежные провайдеры (PSP): команды/вебхуки, fallback-маршрутизация.
KYC/AML: провайдеры, ручные очереди, дедлайны по регуляторике.
Игровые провайдеры: сеттл/репортинг, обработка задержек каналов.
Инцидент-платформа/статус-страница: автоматическое создание/обновление карт.
Release-gates: блокировка опасных релизов при “красных” процессах.

16) Каталог шаблонов (фрагменты DSL)

yaml type: http id: payments_auth retry:
max_attempts: 5 backoff: exponential_jitter timeout: 2s idempotency_key: ${process. deposit_id}
on_fail: compensate: cancel_auth

yaml type: human id: withdrawal_approve sod: true approvers: [Risk, Finance]
sla: 2h on_timeout: escalate: L2

yaml saga:
do:  [reserve_funds, capture, ledger_post]
undo: [ledger_revert, refund_capture, release_funds]

17) Дорожная карта внедрения (8–12 недель)

• Инвентаризация процессов (депозит/вывод/KYC/сеттл), цели SLA, риск-классы.
• Выбор движка/подхода (оркестратор + очереди + хранилище состояний).

• MVP: депозит и вывод как две саги; идемпотентные обработчики; DLQ; базовые метрики/трейсы.

• Human-tasks (4-eyes) для выводов; Policy-as-Code для маршрутизации PSP; таймеры и дедлайны.

• Наблюдаемость (SLO/дашборды), аномалии по длительностям, авто-скейл воркеров; интеграция с инцидент-платформой/статус-страницей.

• Комплаенс: приватность/TTL/аудит WORM; экспорт-workflow; SoD/ABAC.

• Оптимизация стоимости, перф-тесты пиков, tabletop-учения, библиотека шаблонов.

18) KPI/KRI функции

SLA-выполнение процессов, MTTP (mean time to process).
Доля автоматических завершений без ручного участия.
Retried/Task ratio, DLQ rate, Compensation rate.
Время аппрувов (human-tasks) и % просрочки.
Стоимость: $/процесс, $/задачу, $/ретрай.
Риск-сигналы: аномалии по выводу/депозитам, несоответствия SoD.

19) Антипаттерны

Один монолитный процесс на “все” → трудно масштабировать и менять.
Ретраи без идемпотентности → дубли платежей/действий.
Нет дедлайнов/эскалаций → зависшие выводы/KYC.
Хранение PII в контексте процесса без TTL и маскировки.
Компенсации “на бумаге” без автоматизации.
Отсутствие трассировки и аудита → невозможно доказать корректность.

Итог

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