Bieg torrent

Jak skalować platformę kasyna

Pełny artykuł

💡 18+. Materiał techniczny dla iGaming produktów i zespołów inżynieryjnych. Ani telefonu do zabawy.

1) Co dokładnie należy skalować

Ruch i sesje: wybuchy z SEO/strumieni/turniejów (dziesiątki tysięcy RPS na czytanie, tysiące RPS na pismo).

Obwód pieniężny: stawki/rozliczenia/depozyty/gotówki - priorytet integralności i opóźnienia.

Płatności: PSP routing, kaskady, różne geo i handlowców.

Treść: setki dostawców, dziesiątki tysięcy sesji gier równolegle.

Dane: w czasie rzeczywistym KPI prezentuje i raportuje bez blokowania OLTP.

Zgodność: RG/AML/KYC w czasie rzeczywistym.

2) Fundamenty architektoniczne skalowalności

2. 1 Warstwy i podział obowiązków

Krawędź: API-gateway, WAF/bot-protection, rate-limit, geo-filtry.

Usługi domeny: Portfel/Księga, Kasjer, Brama do gier, Bonus, RG, Risk/AML, PAM, Affiliates, CRM.

Warstwa danych: autobus zdarzeń (Kafka/Pulsar), kolejki (SQS/Rabbit), bufory (Redis), OLTP (Postgres/Oracle), OLAP (ClickHouse/Query).

Obserwowalność/SecOps: mierniki/ścieżki/kłody, SIEM/SOAR, skarbiec/HSM.

2. 2 Model zdarzenia + CQRS

Polecenia (rekordy) - ściśle poprzez interfejsy API domeny;

Czytaj - poprzez projekcje (indeksowane widoki/bufory/OLAP).

Outbox/CDC: każde wydarzenie jest publikowane atomowo z transakcją; analityka „słucha” opony, nie bazy danych walki.

2. 3 Sagi i Idempotencja

Długie procesy (depozyt, gotówka, bonus, nagrody turniejowe) - orkiestrowane przez sagi.

Wszystkie polecenia gotówkowe i bonusowe są idempotentne (deduplikacja Idempotence-Key +).

3) Skalowanie środków pieniężnych (nr 1 według priorytetów)

3. 1 Księga jako samodzielna usługa

ACID-DB z podwójnym wpisem (debet/kredyt), niezmiennymi transakcjami, dziennik audytu WORM.

torebka p95 <150ms, „zagubione/powielone osiedla” = 0.

3. 2 Pomocnicy pamięci podręcznej, ale nieprawda

Redis dla limitów, prognoz bilansu, zamków na krótkich odcinkach; portfel pozostaje źródłem prawdy.

Ochrona przed stampedem cache (TTL + jitter, pojedynczy lot).

3. 3 Skalowanie poziome

Strzępki wzdłuż player_id/brand_id/region, gorące strzały - w oddzielne węzły.

Repliki odczytu do projekcji/zaplecza; OLTP i OLAP są oddzielone.

4) Płatności PSP i orkiestra wzrostu

Routing: według BIN/geo/scoring/value; dynamiczna ponowna ocena kanałów.

Kaskadowanie: awaria PSP1 → PSP2 bez utraty koszyka (idempotent tokens).

3-DS/AVS/velocity zasady przy wejściu; przeciwdziałanie oszustwom za pomocą linków graficznych kart/urządzeń.

Uzgodnienia: codzienne automatyczne dopasowywanie rejestrów PSP i rejestrów; ostrzeżenia o rozbieżności.

5) Brama gry i załaduj „eksplozje”

Pojedyncza brama dla dostawców (token-uścisk dłoni, kontrola zdrowia, degradacja „bez nowych sesji”).

Ciśnienie wsteczne i kolejki do rozliczenia, dzięki czemu szczyty dostawcy nie umieścić portfel.

Ograniczenie stawki do poziomu gracza/tabeli/dostawcy; ochrona przed „sztuczkami w grze”.

6) Dane i analizy bez uduszenia produkcji

Outbox/CDC → stream to DWH, SLA display case delivery ≤ 5 min.

Броексий KPI (FTD, NGR, ARPPU, Retention, LTV, Wager Progress, Risk Flags) - мOLAP.

Maskowanie RLS/PII w magazynie; PII odbywa się regionalnie (rezydencja danych).

7) Multi-region/Multi-marka

7. 1 Stabilność geograficzna

Aktywa/aktywa-zobowiązania według regionów, RPO ≤ 5 min, RTO ≤ 30 min.

Geowłóknina PII/pieniądze (EU/UK/BR/...); Zabrania się składania wniosków dotyczących PII w poszczególnych regionach.

7. 2 Multibrand

Ogólne integracje (Game Gateway, Bonus, Affiliates) + odizolowany Ledger/Cashier/PII na licencję/region.

Obowiązkowe klucze 'lokator _ id/brand _ id/license' w autobusie zdarzeń.

8) Obserwowalność, niezawodność, inżynieria chaosu

Metryki: p95/p99 opóźnienia na usługę, poziom błędu, nasycenie, wskaźniki biznesowe (zakłady/min, opóźnienie rozliczenia, sukces depozytu).

Odwzorowanie: pojedynczy 'trace _ id' przez krawędź → domeny → autobus → konsumenci.

Alerting by SLO: błędy SLO-budget i zarządzanie degradacją (zamrażanie bonusów, stop-new-sessions).

Praktyki chaosu: regularne pliki PSP/dostawcy/sieci, kaskady i sagi.

9) skala RG/AML/KYC

Synchroniczne sygnały stop w tempie (depozyt/strata/terminy, samodzielne wyłączenie).

Przepływy sygnału behawioralnego (długie sesje, eskalacja szybkości), proaktywne powiadomienia.

AML: sanclists/PEP, źródło funduszy, SAR/STR - automatyczne rurociągi.

10) Zabezpieczenie „domyślne”

Zero-trust: mTLS, tokeny krótkotrwałe, RBAC/ABAC, zasada najmniejszych praw.

Sekrety - Skarbiec/HSM; Szyfrowanie KMS w spoczynku, tokenizacja PAN (PCI DSS).

WAF/bot ochrony, odciski palców urządzenia, DLP; niezmienny audyt (WORM).

11) FinOps dla skalowalności bez rozszczepienia

Autoskale według mierników biznesowych (zakłady/min, rozliczenie opóźnienia), nie tylko procesor.

Instancje punktowe/przerywalne - dla konsumentów asynchronicznych i ETL.

limity kwot, wpisy budżetowe; Koszty obsługi znaczników i marki

Zapytania/indeksy profilowania; Zasady TTL dla dzienników/mierników.

12) Plan działania na rzecz ewolucji (jeżeli począwszy od monolitu)

1. Wprowadź autobus zdarzeń i jeden słownik ('bet. placed', 'bet. settled ',' portfel. debet/kredyt ',' depozyt. odniosła sukces ").

2. Przenieś Ledger do oddzielnej usługi/bazy danych z outbox i idempotence.

3. Oddzielna kasa (orkiestra PSP, kaskady, pojednania).

4. Umieść Game Gateway i degradacji „bez nowych sesji”.

5. Konwertuj Bonus/RG na subskrypcję zdarzeń; zabronić ręcznych edycji.

6. Post OLTP/OLAP i skonfigurować strumienie CDC w DWH.

7. Umożliwia obserwację (SLO-deski rozdzielcze, śledzenie) i ćwiczenia chaosu.

8. Przygotowanie wielu regionów (dane/klucze/środki/PII) - zgodnie z priorytetami geo.

13) minimum SLO dla dojrzałej platformy

Czas uptime jądra (Portfel/Kasjer/Game Gateway) ≥ 99. 95%.

p95 Ledger <150 ms; Autoryzacja kasjera <3 s; powodzenie depozytu ≥ 85% w geo docelowym.

„Zagubione/powielone osiedla” = 0.

Dostarczenie imprez do BI ≤ 5 min.

MTTR zdarzeń rdzenia <30 min.

14) Lista kontrolna skalowalności architekta

Domeny są oddzielone; pieniądze to oddzielny Ledger z skrzynką rozdzielczą/CDC.
Polecenia są idempotentne; klucze deduplikacji są wszędzie.
Gra Gateway z trybem ciśnienia wstecznego i degradacji.
Kasjer: kaskady PSP, przekładki, pojednania, telemetria usterek.
CQRS/projekcje; OLTP i OLAP są fizycznie oddzielne.
Autobus imprezowy z rejestrem schematu; weryfikację kontraktu.
RG/AML - synchroniczne światła hamulcowe; rejestry i raporty są zautomatyzowane.
Obserwowalność: mierniki/ścieżki/kłody z 'trace _ id' i znacznikami marki/najemcy.
Plan DR: aktywa/zobowiązania, RPO ≤ 5 min, RTO ≤ 30 min; regularne ćwiczenia.
Bezpieczeństwo: mTLS, Vault/HSM, PCI/RODO, WAF/bot protection, audyt WORM.
FinOps: autoskale według mierników biznesowych, wpisy budżetowe, znaczniki kosztów.

15) Anty-wzory (czerwone flagi)

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

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

Publikowanie zdarzeń związanych z omijaniem transakcji (brak sklepu).

Brak degradacji: „albo wszystko, albo upadek”.

Awarie płatności bez kaskad i telemetrii.

Brak idempotencji; retrasy tworzą podwojenie osiedli.

Brak geoizolacji PII i kluczy handlowych.

Śledztwa trwają godzinami.

Skalowalność platformy kasynowej nie jest „więcej serwerów”, ale prawidłowe granice i model operacyjny wydarzenia: izolowana i szybka pętla pieniężna, stabilna warstwa płatności, brama do gier z kontrolowaną degradacją, separacja OLTP/OLAP, obserwowalność i dyscyplina SRE/FinOps. Na takim fundamencie platforma będzie spokojnie żyć szczyty turniejów, nowe geo i dziesiątki marek - bez ryzyka dla pieniędzy i reputacji graczy.