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

1) Зачем микросервисы в iGaming

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

Когда не стоит: маленькая команда/объем, нет DevOps-практик, слабая автоматизация тестов — тогда модульный монолит лучше.

2) Домены, границы и команды (DDD + Team Topologies)

Доменные контуры: Аккаунт/Профиль, KYC/Комплаенс, Платежи/Кошелек, Игровой Контент/Агрегация, Бонусы/Миссии, Турниры, Маркетинг/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` сквозь шлюз→сервисы→БД).
Метрики: 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 сервис↔сервис (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/Комплаенс

Сервисы: `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 критичных флоу (регистрация→депозит→старт игры→вывод).
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, региональные данные.
Сначала модульный монолит, потом эволюция — если масштабы и команда готовы.