Мікросервісна архітектура

1) Навіщо мікросервіси в iGaming

Швидкість змін: незалежні релізи фіч команд (платежі, контент, ризик, турніри).
Надійність: відмова одного сервісу не валить весь продукт (межі відмови).
Масштаб: горизонтальний скейл «гарячих» доменів (гаманець, лобі, стріми).
Комплаєнс: сегрегація даних по регіонах/юрисдикціях.

Коли не варто: маленька команда/об'єм, немає DevOps-практик, слабка автоматизація тестів - тоді модульний моноліт краще.

2) Домени, межі та команди (DDD + Team Topologies)

Доменні контури: Акаунт/Профіль, КУС/Комплаенс, Платежі/Гаманець, Ігровий Контент/Агрегація, Бонуси/Місії, Турніри, Маркетинг/CRM, Звітність/BI.
Bounded Context = договір про модель даних і мову.
Потоки змін ↔ команди: одна команда = один контур + свої SLO.
BFF (Backend for Frontend): окремі фасади під Web/Mobile/Partner, щоб не збирати «оркестрацію» на клієнті.

3) Комунікації: синхрон vs асинхрон

Синхрон (REST/gRPC): коли потрібна негайна відповідь (перевірка лімітів при депозиті).
Асинхрон (Kafka/NATS/SQS): події та фонові процеси (нарахування кешбеку, розсилки, оновлення рейтингів).

• Критичний шлях = мінімум мережевих хопів.
• Міждоменна інтеграція - через події та договірні API.
• Не будувати «ланцюжки з 5 + синхронних викликів» в онлайні → використовувати EDA/саги.

4) Контракти та версіонування

Контракт-перший: OpenAPI/AsyncAPI + Schema Registry (Avro/JSON Schema).
SemVer + сумісність: додавання полів не ламає клієнтів.
Consumer-driven contracts (CDC): автоперевірки в CI (проти регресій).
Deprecation policy: вікно підтримки (12-18 міс), телеметрія за старими версіями.

5) Події, саги і консистентність

Outbox/Transaction Log Tailing: атомний запис «дані + подія».

• Оркестрація (центральний координатор) для платежів/висновків.
• Хореографія (реакція на події) для бонусів/місій.
• Ідемпотентність: ключі на'entityId + action + nonce', зберігання dedup-реєстру.
• Консистентність: «зовнішня» - через події; «внутрішня» - транзакції в межах сервісу.

6) Дані та зберігання

Принцип «свій стор»: кожен сервіс володіє своєю БД (ізоляція схем).

• Транзакції/баланси - реляційні (PostgreSQL) з суворими інваріантами.
• Події/лог - append-only (Kafka/Redpanda).
• Кеш/сесії - Redis/KeyDB; лідерборди - Redis Sorted Sets.
• Пошук - OpenSearch/Elastic.
• Матеріалізовані проекції для читання (CQRS) - швидкі списки/звіти.

7) Надійність і стійкість

Timeouts/Retry with jitter/Retry-budget тільки для ідемпотентних операцій.
Circuit-breaker/Outlier-ejection між сервісами.
Bulkhead: окремі пули на «галасливі» апстріми.
Rate limits per-client/route, backpressure (503 + Retry-After).
Dead-letter + poison-message handling в чергах.

8) Спостережуваність (Observability)

Трасування: OpenTelemetry ('trace _ id'крізь shlyuz→servisy→BD).
Метрики: RPS, p50/p95/p99, error rate 4xx/5xx, saturation (CPU/mem/queue), бізнес-метрики (TTP, TtW).
Логи: структурний JSON, маскування PII/PAN/IBAN, кореляція по'trace _ id'.
SLO/алерти: на маршрут/функцію (наприклад,'Deposit p95 ≤ 300 ms','success ≥ 98. 5%`).

9) Безпека та комплаєнс

Zero-Trust: mTLS servis↔servis (SPIFFE/SPIRE), короткоживучі сертифікати.
AuthN/Z: OAuth2/JWT (aud/scope/exp), атрибутне розмежування ролей.
Секрети: KMS/Secrets Manager/Sealed Secrets, ротація ключів.
GDPR/локалізація даних: регіональні кластери, geo-fencing на API-шлюзі.
Аудит: незмінювані журнали (WORM), трасування адмін-дій.

10) Розгортання та релізи

Контейнери/K8s: один сервіс = один deploy; ресурси/ліміти; PodDisruptionBudget.
CI/CD: лінтери, unit/contract/integ-тести, security scan, SBOM.
Релізи: canary/blue-green/shadow, міграції схем через expand-and-contract.
Автоскейл: HPA по CPU+RPS+p95+queue-depth; drain при згортанні.

11) Продуктивність і вартість

Профілювання: p95/99 «за сервісами та методами», flame-графи.
Кешування: read-through/write-through; TTL/інвалідація по подіям.
Data locality: тримати гарячі дані близько до обчислення.
FinOps: таргет завантаження 60-70%, «warm pools», авто-пауза неактивних воркерів.

12) Шаблони доменів (iGaming)

12. 1 Платежі/Гаманець

Сервіси: `payments-gw` (фасад), `wallet`, `psp-adapters-`, `fraud-check`.
Потік: `init → reserve → capture/rollback` (сага).
Події: `PaymentInitiated`, `PaymentAuthorized`, `PaymentSettled/Failed`.
Ідемпотентність: 'Idempotency-Key', дедуп в'wallet'.

12. 2 КУС/Комплаенс

Сервіси: `kyc-flow`, `doc-storage`, `sanctions-check`, `pep-screening`.
Події: `KycSubmitted/Approved/Rejected`, `RiskScoreUpdated`.
Аудит та ETA: черга завдань, тайм-лайн кейса, post-actions.

12. 3 Бонуси/Місії

Сервіси: `bonus-engine`, `wallet-bonus`, `eligibility`.
Хореографія: `BetPlaced → BonusEngine → BonusGranted → WalletCredited`.
Захист від зловживань: idempotent гранти, ліміти, симулятор правил.

12. 4 Турніри/Лідерборди

Сервіси: `tournament-svc`, `scoring`, `leaderboard`.
Зберігання: Redis ZSET + періодична «скидання» в OLAP.
Події: `ScoreUpdated`, `TournamentClosed`, `RewardIssued`.

13) Приклад «контракт + подія» (спрощено)

OpenAPI (фрагмент) - Wallet

yaml paths:
/v1/wallet/{userId}/credit:
post:
requestBody:
content:
application/json:
schema:
$ref: '#/components/schemas/CreditRequest'
responses:
'202': { description: 'Enqueued' }
components:
schemas:
CreditRequest:
type: object required: [amount, currency, reason, idempotencyKey]
properties:
amount: { type: number }
currency: { type: string, example: UAH }
reason: { type: string, enum: [Deposit, Bonus, Adjustment] }
idempotencyKey: { type: string }

AsyncAPI (фрагмент) - подія

yaml channels:
wallet. credit. applied:
publish:
message:
name: WalletCreditApplied payload:
type: object required: [userId, amount, currency, sourceEventId]

14) Тестування

Unit/Property-based для доменних правил.
CDC (Pact/Assertible) - контракт-тести провайдерів/споживачів.
Інтеграційні з локальними брокерами (Testcontainers).
E2E критичних флоу (registratsiya→depozit→start igry→vyvod).
Chaos/Failover-тести: відключення PSP/падіння брокера/втрата зони.

15) Метрики та SLO (мінімум)

Доступність сервісів: `≥99. 9%'для платіжних/гаманця.
Latency p95: API критичного шляху ≤ 300-500 мс.
Error budget: 0. 1–0. 5% в квартал, burn-alerts.
Черги: lead time події (produce→consume), DLQ ≤ 0. 1%.
Бізнес: TTP, TtW, FTD-success, KYC-TtV.

16) Чек-листи

Проектування сервісу

• Чітка доменна межа і власник даних.
• Контракти OpenAPI/AsyncAPI + схеми в Registry.
• SLO/алерти визначені; метрики/трейси/логи вбудовані.
• Політики таймаутів/ретраїв/ідемпотентності.
• Міграції схем: expand-and-contract.

Перед релізом

• Unit/CDC/інтеграційні тести зелені.
• Канарський маршрут і план відкату.
• Rate-limits/вагові маршрути налаштовані.
• Секрети/ключі/сертифікати ротуються.
• Фіча-прапори і фоллбеки підготовлені.

17) Анти-патерни

Мережа як шина даних: глибокі синхронні ланцюжки замість подій.
Загальний «бог» -БД на всі сервіси.
Відсутність ідемпотентності → подвійні списання/нарахування.
Темні релізи без телеметрії і kill-switch.
Прихована сесійність (липкість всюди замість зовнішнього стану).
Контракти «в коді» без версії і CDC.
Логіка в API-шлюзі замість сервісів (шлюз = тонкий).

18) Міграція з моноліту (Strangler Fig)

1. Виділити фасад-шлюз і перший контур (наприклад, платежі).
2. Зняти двійкове логування (outbox) з моноліту в події.
3. Поступово переводити ендпойнти на новий сервіс (маршрутизація/канарські ваги).
4. Стиснути моноліт до «ядра» і відключити.

19) Стек та інфраструктура (приклад)

Комунікації: REST/gRPC, Kafka/NATS; Schema Registry.
Сховища: PostgreSQL, Redis, OpenSearch, S3/MinIO; OLAP — ClickHouse/BigQuery.
Контейнери/оркестрація: Docker, Kubernetes (Ingress/Gateway), Service Mesh (Istio/Linkerd) при необхідності.
Шлюз: Envoy/Kong/Traefik/NGINX.
CI/CD: GitHub Actions/GitLab CI + ArgoCD/Flux; Pact/OWASP/ZAP.
Observability: OpenTelemetry, Prometheus, Tempo/Jaeger, Loki.

20) Підсумкова шпаргалка

Проектуйте межі по доменах і відповідальності даних.
Синхрон - тільки там, де потрібна відповідь зараз; решта - події.
Контракти/схеми/CDC - страховка від регресій.
Саги + outbox + ідемпотентність - фундамент надійності.
Спостережуваність і SLO - не опція, а критерій «готове».
Релізи через canary/blue-green, міграції - expand-and-contract.
Безпека/комплаєнс: mTLS, JWT, KMS, регіональні дані.
Спочатку модульний моноліт, потім еволюція - якщо масштаби і команда готові.