Niyə iGaming mikroservislərə keçir
Məqalənin tam mətni
1) Kontekst: monolit niyə fəaliyyətini dayandırdı
iGaming məzmun, coğrafiya və tənzimləmələrə görə böyüyür. Monolit kod bazası:- buraxılışları yavaşlatır (ümumi deploy pəncərələr, reqressiya riski), zəif miqyaslı (cüzdan və kassa - isti, və CMS - soyuq), tələblərə uyğunluğa mane olur (müxtəlif tənzimləyicilər → müxtəlif məlumat qaydaları), pul izolyasiyasını çətinləşdirir (pul-flows və bonuslar bükülmüş).
Nəticə - hadisələrin yüksək riskləri və yavaş vaxt-to-market.
2) Mikroservis yanaşması nə verir
1. Kritik domenlərin izolyasiyası. Cüzdan/Ledger, Cashier/PSP, Bonus Engine, Game Sessions, KYC/AML, RG, Risk/Fraud, Affiliates, CRM - SLO ilə fərdi xidmətlər.
2. İstehlak miqyası. Isti xidmətlər (cüzdan, kassa, oyun sessiyası) bütün klasteri şişirtmədən daha çox resurs əldə edir.
3. Müstəqil buraxılışlar. Komandalar öz dövrü üzrə deploat (kanarya relizləri, feature-bayraqlar).
4. Uğursuzluğa davamlılıq. Lokal deqradasiya bütün məhsulu məhv etmir (cashier deqradasiya edir - oyunlar keşlər və növbələr hesabına davam edir).
5. Hüquqi seqmentasiya. Bölgələr üzrə PII və ödənişlərin çeşidi (EU/UK/BR) və data-rezidentlik.
6. İnteqrasiyanın çevikliyi. Paralel oyun provayderləri, PSP və KYC provayderləri.
3) Əsas sxem (sadələşdirilmiş)
Edge qat: API Gateway, WAF/bot qorunması, rate limiting, geo-filtrlər.
Domen mikroservisləri: Wallet/Ledger, Bonus, Cashier, Game Gateway, Risk/Fraud, RG, KYC/AML, Affiliates, CRM, CMS, Reporting/Compliance.
Hadisə şinası: Kafka/Pulsar - 'bet. placed`, `bet. settled`, `wallet. debit/credit`, `cashier. deposit. succeeded`, `rg. limit. hit`, `bonus. consumed 'və s.
Məlumat: OLTP DD Service, outbox/CDC → DWH (ClickHouse/BigQuery).
Observability: metrik/log/treys; SIEM/SOAR; audit-log WORM.
4) Pul və bütövlük: niyə miqrasiya açarı
Mikroservislərin əsas arqumenti pul dövrəsinin sərt izolyasiyasıdır:- ciddi ACID və idempotentlik komandaları ilə ayrı Ledger, uzun proseslər üçün dastanlar (depozitlər, cashout, bonus hesablamaları), outbox + hadisələrin əməliyyat nəşri, sıfır tolerantlıq «əl düzəlişləri» balansları.
Bu dizayn memarlıq səviyyəsində settlementlərin itirilməsi/təkrarlanması ehtimalını sıfıra endirir.
5) Mikroservislərin uçmayacağı patternlər
CQRS + proyeksiyaları. Komandalar - ciddi domen API vasitəsilə; oxu - proyeksiya modelləri vasitəsilə.
Idempotency Keys. Hər bir pul/bonus komandası yan təsirsiz təkrar olunur.
Dastanlar və kompensasiyalar. «BD geri qaytarılması» əvəzinə aydın kompensasiya hadisələri.
Schema Registry. Hadisə müqavilələrinin versiyası; prodüserlərin/konsumerlərin uyğunluğu.
Rate limits/Retry/Backoff. Şəbəkə nasazlıqları normadır; müştəri sabitliyi.
Zero-trust və sirləri. mesh daxilində mTLS, Vault/HSM, minimum imtiyazlar.
6) Mikroservislərdə daha çətin olan (düzünü desəm, mənfi cəhətlər haqqında)
Şəbəkə yaddaşdan daha bahalıdır. Daha çox RPC, gizli artım və infrastruktur dəyəri.
Verilənlərin mürəkkəbliyi. Tutarlılıq - Ledgera xaricində eventual, proyeksiyalara ehtiyac var.
Müşahidə. İzləmə və SLO olmadan hər şey tez bir zamanda «qara qutuya» çevrilir.
Komanda intizamı. Müqavilə testləri, rituallar, sxemlərin miqrasiyası - məcburidir.
Kross-regional boşluqlar. Data residency düşünülmüş şardizasiya tələb edir.
Şirkət DevOps/SRE mədəniyyətinə hazır deyilsə, «yaxşı modulluq» monolit daha yaxşı ola bilər.
7) Addım-addım miqrasiya: monolitdən xidmətlərə
Addım 1. Hadisələri standartlaşdırın. Bir şin və vahid lüğət daxil edin: oyunçu, bahis, düzəliş, depozit, bonus.
Addım 2. Ledger çıxarın. Pul konturu ilk ayrılır: ayrı DB, API komandaları, outbox.
Addım 3. Cashier ayırın. PSP orkestrasiyası, kaskadlar, 3-DS, yoxlamalar - müstəqil xidmət kimi.
Addım 4. Game Gateway. Oyun provayderlərinə vahid şlyuz; sessiyalar/kollbeklər - monolit vasitəsilə deyil.
Addım 5. Bonus Engine и RG. Qaydalar, veycer, limitlər - müstəqil, cüzdan/oyun hadisələrinə abunə.
Addım 6. Risk/AML + KYC. Öz inteqrasiyaları və alertinqləri ilə ayrıca kontur.
Addım 7. Məlumat və BI. CDC DWH, KPI vitrinlər, anti-Excel hesabat.
Addım 8. Back-office. RBAC/ABAC, audit-log, krit aksiyaları üçün «4 göz».
Paralel olaraq - kanarya relizləri, ficheflages, rollback, müntəzəm DR təlimləri.
8) Əməliyyat təcrübəsi: hansı SLO norma hesab
Aptime nüvə (wallet/cashier/game-gateway) ≥ 99.95%.
p95 cüzdan gecikmə <150 ms; cashier avtorizasiya <3 s.
«İtirilmiş/dublyaj edilmiş settlementlər» = 0.
Hadisələrin BI vitrinlərinə çatdırılması ≤ 5 dəq.
MTTR nüvə hadisələri <30 dəq.
9) Təhlükəsizlik və uyğunluq «default»
PII/ödəniş məlumatlarının seqmentasiyası, PCI DSS, GDPR/yerli analoqlar.
At-rest/in-transit şifrələmə, qısa ömürlü tokenlər, açarların rotasiyası.
WAF/bot qorunması, device-fingerprinting, velocity anomaliyalar.
WORM-saxlama auditi, ən kiçik hüquqlar prinsipi ilə giriş.
10) İqtisadiyyat və təşkilati effektlər
TTR relizlər ↓: müstəqil deploes vəzifələr və kontekst-svitch növbələri azaldır.
Cost-to-scale ↓/↑: üfüqi miqyas nöqtəsi daha ucuzdur, lakin düşünülmüş FinOps (avtoskeyl, limitlər, spot-instansiyalar) lazımdır.
Hadisə riski ↓: blast radius xidmət ilə məhdudlaşır.
Məhsul sürəti ↑: yeni provayderlər/PSP və fiçlər «ümumi pəncərə» gözləmir.
11) Mikroservis iGaming nüvəsinin yetkinlik yoxlama siyahısı
- Ledger - ayrı xidmət və DB, yalnız komanda API, outbox/CDC.
- Bütün pul/bonus əməliyyatları idempotent, deduplikasiya açarları - hər yerdə.
- Sxemlərin reyestri ilə hadisələrin şinası; backward-compatible müqavilələr.
- PSP kaskadı və gündəlik işıqlandırma ilə Cashier.
- Hadisə zamanı «no new sessions» deqradasiyası ilə Game Gateway.
- RG/AML - sinxron stop siqnalları, real-yoxlamalar.
- Observability: Metrics/Logi/Tracks vasitəsilə trace_id; SLO daşbordları.
- DR planı: RPO ≤ 5 dəq, RTO ≤ 30 dəq; müntəzəm təlimlər.
- Data residency və PII maskalama; RBAC/ABAC və «4 göz».
- Excel olmadan BI: KPI vitrinləri, kokortlar, LTV, tənzimləyicilərə hesabatlar.
12) Qırmızı bayraqlar (anti-pattern)
DB-də balans/bonusların əl ilə düzəldilməsi.
Vahid DB «hər şeyə», BI döyüş cədvəllərini vurur.
Domen əməliyyatlarının «yan keçməsi» hadisələrinin yayımlanması (heç bir outbox).
Hadisə sxemlərinin versiyası yoxdur.
Sıfır idempotentlik və retraj «necə olur».
Kaskadsız və detallı telemetriyasız ödəniş imtinaları.
Kritik yollarda RG/AML stop siqnalları yoxdur.
iGaming-dəki mikroservislər dəbə hörmət deyil, pul, risk və məhsulu müstəqil konturlara ayırmaq, buraxılışları sürətləndirmək və hadisələrin miqyasını azaltmaq üçün bir yoldur. Açar - pul bütövlüyü (Ledger + idempotentlik + dastanlar), hadisə (şin + müqavilələr) və SRE/DevOps mədəniyyəti. Bu təməl ilə platforma sürətli, şəffaf və təhlükəsiz qalmaqla trafik, coğrafiya və tənzimləmə tələblərinin artmasına tab gətirir.
