Микросервистік сәулет

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 (Euro/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/деректерді оқшаулау: өңірлік кластерлер, API-шлюздегі geo-fencing.
Аудит: өзгермейтін журналдар (WORM), әкімшілік әрекеттерді трассалау.

10) Тарату және релиздер

Контейнерлер/K8s: бір қызмет = бір deploy; ресурстар/лимиттер; PodDisruptionBudget.
CI/CD: линтерлер, unit/contract/integ-тестілер, security scan, SBOM.
Релиздер: canary/blue-green/shadow, expand-and-contract арқылы схемаларды көшіру.
Автоскейл: CPU + RPS + p95 + queue-depth бойынша HPA; бұрылғанда 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 (тіркеу → депозит → ойын бастау → шығару).
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, аймақтық деректер.
Алдымен модульдік монолит, содан кейін эволюция - егер ауқым мен команда дайын болса.