GH GambleHub

Рушій робочих процесів

1) Навіщо потрібен рушій

У iGaming безліч наскрізних процедур: депозит/висновок, KYC/AML, обробка ставок/сетлів, виплати переможцям, протифродові розслідування, бонусні кампанії, інцидент-менеджмент. Workflow Engine робить їх:
  • Передбачуваними: явні кроки, статуси, 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)

Service task (HTTP):
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
Human task (4-eyes):
yaml type: human id: withdrawal_approve sod: true approvers: [Risk, Finance]
sla: 2h on_timeout: escalate: L2
Compensation saga:
yaml saga:
do:  [reserve_funds, capture, ledger_post]
undo: [ledger_revert, refund_capture, release_funds]

17) Дорожня карта впровадження (8-12 тижнів)

Нед. 1–2:
  • Інвентаризація процесів (депозит/виведення/КУС/сеттл), цілі SLA, ризик-класи.
  • Вибір рушія/підходу (оркестратор + черги + сховище станів).
Нед. 3–4:
  • MVP: депозит і висновок як дві саги; ідемпотентні обробники; DLQ; базові метрики/трейси.
Нед. 5–6:
  • Human-tasks (4-eyes) для висновків; Policy-as-Code для маршрутизації PSP; таймери і дедлайни.
Нед. 7–8:
  • Спостережуваність (SLO/дашборди), аномалії за тривалостями, авто-скейл воркерів; інтеграція з інцидент-платформою/статус-сторінкою.
Нед. 9–10:
  • Комплаєнс: приватність/TTL/аудит WORM; експорт-workflow; SoD/ABAC.
Нед. 11–12:
  • Оптимізація вартості, перф-тести піків, tabletop-навчання, бібліотека шаблонів.

18) KPI/KRI функції

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

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

Один монолітний процес на «все» → важко масштабувати і змінювати.
Ретраї без ідемпотентності → дублі платежів/дій.
Немає дедлайнів/ескалацій → завислі висновки/КУС.
Зберігання PII в контексті процесу без TTL і маскування.
Компенсації «на папері» без автоматизації.
Відсутність трасування і аудиту → неможливо довести коректність.

Підсумок

Рушій робочих процесів - це система управління життєвим циклом бізнес-операцій: оркестрація критичних шляхів, стійкість (ідемпотентність, ретраї, саги), формалізована участь людей, політика безпеки і комплаєнсу, наскрізна спостережуваність і контроль вартості. Такий контур робить iGaming-платформу передбачуваною в піках, швидкою в інцидентах і переконливою для регуляторів і партнерів.

Contact

Зв’яжіться з нами

Звертайтеся з будь-яких питань або за підтримкою.Ми завжди готові допомогти!

Telegram
@Gamble_GC
Розпочати інтеграцію

Email — обов’язковий. Telegram або WhatsApp — за бажанням.

Ваше ім’я необов’язково
Email необов’язково
Тема необов’язково
Повідомлення необов’язково
Telegram необов’язково
@
Якщо ви вкажете Telegram — ми відповімо й там, додатково до Email.
WhatsApp необов’язково
Формат: +код країни та номер (наприклад, +380XXXXXXXXX).

Натискаючи кнопку, ви погоджуєтесь на обробку даних.