Dlaczego iGaming przechodzi na mikroservice

Pełny artykuł

💡 18+. Materiał jest edukacyjny. Ani telefonu do zabawy. Nacisk położony jest na przyczyny inżynieryjne zmiany architektury.

1) Kontekst: dlaczego monolit przestał działać

iGaming rośnie w treści, geografii i regulacji. Monolityczna baza kodowa:

zwalnia zwolnienia (ogólne okna depla, ryzyko regresji), słabo skaluje się (portfel i pulpit są gorące, a CMS jest zimny), zakłóca zgodność (różne regulatory → różne zasady danych), komplikuje izolację pieniędzy (przepływy pieniężne i premie są ze sobą powiązane).

Rezultatem jest wysokie ryzyko incydentów i powolny czas na rynku.

2) Co daje podejście mikroservice

1. Izolacja domen krytycznych. Portfel/Księga, Kasjer/PSP, Bonus Engine, Sesje gier, KYC/AML, RG, Risk/Fraud, Affiliates, CRM - oddzielne usługi z własnymi SLO.

2. Skalowanie przez zużycie. Gorące usługi (portfel, kasa, sesja gier) uzyskać więcej zasobów bez nadmuchiwania całego klastra.

3. Niezależne wydania. Polecenia zubożają się zgodnie z ich cyklem (wydania kanaryjskie, flagi funkcji).

4. Tolerancja błędów. Lokalna degradacja nie obniża całego produktu (degradacje kasjerskie - gry trwają z powodu buforów i kolejek).

5. Segmentacja prawna. PII i płatności w podziale na regiony (UE/Wielka Brytania/BR) i miejsce zamieszkania.

6. Elastyczność integracji. Równoległe połączenie dostawców gier, dostawców PSP i KYC.

3) Program podstawowy (uproszczony)

Warstwa krawędzi: Brama API, ochrona WAF/bot, ograniczenie prędkości, filtry geo.

Mikroservice domeny: Portfel/Księga, Bonus, Kasjer, Brama gier, Ryzyko/Oszustwo, RG, KYC/AML, Partnerzy, CRM, CMS, Sprawozdawczość/Zgodność.

Autobus imprezowy: Kafka/Pulsar - 'bet. placed', 'bet. settled ',' portfel. debet/kredyt ',' kasjer. depozyt. Udało się „,” rg. limit. hit ',' bonus. spożywane ", itp.

Dane: Baza danych OLTP dla usługi, outbox/CDC → DWH (ClickHouse/Query).

Obserwowalność: mierniki/kłody/szlaki; SIEM/SOAR; dziennik audytu WORM.

4) Pieniądze i integralność: Dlaczego jest to klucz do migracji

Głównym argumentem „dla” mikroservices jest sztywna izolacja obwodu monetarnego:

oddzielny Księga z ścisłym ACID i polecenia idempotence, sagi dla długich procesów (depozyty, cashout, bonus memoriały), outbox + transactional event publishing, zero tolerancji dla „ręcznych edycji” sald.

Konstrukcja ta zmniejsza prawdopodobieństwo utraty/powielania osiedli do zera na poziomie architektonicznym.

5) Wzory, bez których mikroservice nie wystartują

Projekcje CQRS +. Polecenia - ściśle poprzez interfejsy API domeny; czytanie - poprzez modele projekcyjne.

Idempotence Keys. Każdy zespół pieniędzy/bonusów jest powtarzalny bez skutków ubocznych.

Sagi i odszkodowania. Wyraźne kompensowanie zdarzeń zamiast „DB rollback”.

Rejestr schematu. Umowa zdarzenia Versioning producent/konsument kompatybilność.

Limity stawki/Wznowienie/Backoff. Awarie sieci są normą; stabilność klienta.

Zero zaufania i tajemnic. mTLS wewnątrz siatki, Vault/HSM, minimalne uprawnienia.

6) Co jest trudniejsze w mikroservice (uczciwe o minusach)

Sieć jest droższa niż pamięć. Więcej RPC, zwiększone opóźnienia i koszty infrastruktury.

Złożoność danych. Spójność - ostatecznie poza Ledgera, projekcje potrzebne.

Obserwowalność. Bez śledzenia od końca i SLO wszystko szybko zamienia się w czarną skrzynkę.

Dyscyplina drużyny. Wymagane są testy kontraktowe, rytuały zwolnienia, migracje systemowe.

Różnice międzyregionalne. Rezydencja danych wymaga przemyślanej szardyzacji.

Jeśli firma nie jest gotowa do kultury DevOps/SRE, monolit „o dobrej modułowości” może być lepszy.

7) Migracja krok po kroku: od monolitu do usług

Krok 1. Ujednolicenie wydarzeń. Wprowadź oponę i jeden słownik: gracz, zakład, rozliczenie, depozyt, bonus.

Krok 2. Wyjmij Ledgera. Obwód pieniędzy jest najpierw oddzielony: oddzielna baza danych, polecenie API, skrzynka odbiorcza.

Krok 3. Oddzielna kasa. Orkiestra PSP, kaskady, 3-DS, pojednania - jako niezależna usługa.

Krok 4. Gra Gateway. Pojedyncza brama dla dostawców gier; sesje/kolbecki - nie przez monolit.

Krok 5. Bonus Engine dla RG. Zasady, vager, limity - offline, subskrypcja portfela/gry.

Krok 6. Ryzyko/AML + KYC. Oddzielny obwód z własnymi integracjami i wpisami.

Krok 7. Dane i BI. CDC w DWH, prezentacje KPI, raportowanie anty-Excel.

Krok 8. Na zapleczu. RBAC/ABAC, dziennik audytu, „4 oczy” dla akcji na Krecie.

Równolegle - kanarkowe wydania, phicheflags, rollback, regularne ćwiczenia DR.

8) Doświadczenie operacyjne: które SLO są uważane za normę

Czas uptime jądra (portfel/kasjer/gra-gateway) ≥ 99. 95%.

p95 opóźnienie portfela <150 ms; autoryzacja kasjera <3 s.

„Zagubione/powielone osiedla” = 0.

Dostarczenie imprez do BI-showcases ≤ 5 min.

MTTR dla zdarzeń podstawowych <30 min.

9) Bezpieczeństwo i zgodność „domyślnie”

Segmentacja danych PII/płatniczych, PCI DSS, RODO/analogi lokalne.

Szyfrowanie w czasie odpoczynku/tranzytu, krótkotrwałe żetony, rotacja klucza.

Ochrona WAF/bot, odciski palców, anomalie prędkości.

Rejestry audytu w magazynie WORM, dostęp zgodnie z zasadą najmniejszych praw.

10) Ekonomia i efekty organizacyjne

Wersje TTR, z wyłączeniem: Niezależne wysyłki zmniejszają kolejki zadań i przełącznik kontekstowy.

Kosztowo-skalarne wibracje: skalowanie poziome jest znacznie tańsze, ale potrzebujesz dobrze przemyślanych FinOpów (autoskale, limity, instancje punktowe).

Ryzyko wystąpienia incydentów: promień wybuchu jest ograniczony do serwisu.

Prędkość produktu: nowi dostawcy/dostawcy usług płatniczych i funkcje nie oczekują „wspólnego okna”.

11) Lista kontrolna dojrzałości rdzenia Microservice iGaming

Ledger - oddzielna usługa i baza danych, tylko polecenie API, skrzynka odbiorcza/CDC.
Wszystkie transakcje gotówkowe/bonusowe są idempotentne, klucze deduplikacji są wszędzie.
Autobus imprezowy z rejestrem obwodów; kontrakty kompatybilne wstecz.
Kasjer z kaskadą PSP i dziennymi iskrami.
Gra Gateway z „żadnych nowych sesji” degradacji w incydentach.
RG/AML - synchroniczne sygnały stop na zakładzie, kontrola rzeczywistości.
Obserwowalność: mierniki/kłody/ścieżki na trace_id od końca do końca; deski rozdzielcze SLO.
DR-plan: RPO ≤ 5 min, RTO ≤ 30 min; regularne ćwiczenia.
Pobyt danych i maskowanie PII; RBAC/ABAC i „4 oczy”.
BI bez instrukcji Excel: prezentacje KPI, kohorty, LTV, raporty dla regulatorów.

12) Czerwone flagi (Antipatterns)

Ręczne edycje sald/bonusów w bazie danych.

Pojedyncza baza danych „za wszystko”, BI uderza w stoły bitewne.

Publikowanie zdarzeń „omijających” transakcje domeny (brak skrzynki odbiorczej).

Brak wersji schematu zdarzeń.

Zero idempotencji i retrai „jak się okazuje”.

Awarie płatności bez kaskady i szczegółowej telemetrii.

Brak świateł RG/AML na ścieżkach krytycznych.

Mikroservice w iGaming nie są hołdem dla mody, ale sposobem na rozłożenie pieniędzy, ryzyka i produktu wzdłuż niezależnych konturów, przyspieszenie zwolnień i zmniejszenie skali incydentów. Kluczem jest integralność monetarna (Ledger + idempotency + sagi), pełnia wydarzeń (opony + umowy) i kultura SRE/DevOps. Dzięki temu fundamentowi platforma może wytrzymać wzrost ruchu, geografii i wymogów regulacyjnych, pozostając szybka, przejrzysta i bezpieczna.