Jak działa architektura backend kasyna

1) Cały obraz: domeny i strumienie danych

Kluczowe domeny:

Tożsamość i konta - rejestracja, uwierzytelnianie, role, urządzenia, sesje.
Portfel & Ledger - konta gotówkowe, portfele bonusowe, transakcje, księga (tylko dodatek).
Gry i zakłady - sesje gier, zakłady, rundy, obliczanie wyników, integracja (RNG/Live/Crash, itp.).
Bonusy i promocje - freespins, cashback, bony, zakłady (zakłady), anty-nadużycia.
Płatności (Kasjer) - na rampie/poza rampą: mapy, APM, crypt/stablecoins, wiązanie KYC.
KYC/AML/KYT & RG - weryfikacja tożsamości/adresu/przychodów, kontrola transakcji, limity czasowe.
Ryzyko i zgodność - limity stawek/płatności, listy sankcji, blokowanie geograficzne, audyt.
Katalog & Lobby - lista dostawców, gier, kategorii, limitów; Warianty A/B.
Reporting & BI - P&L, GGR/NGR, retencja, cykl życia gracza, podmioty powiązane.
Obserwacja i operacje - dzienniki, mierniki, ślady, wpisy, sygnały oszustwa.

Orkiestra: nowoczesna platforma jest zbudowana na imprezie: wydarzenia wymiany usług za pośrednictwem autobusu (Kafka/NATS), operacje krytyczne są liniowe (portfel/księga), podsystemy boczne są podpisywane i odpowiadają asynchronicznie (bonusy, BI, powiadomienia).

2) Model warstwowy

Warstwa krawędzi: brama API, ochrona WAF/bot, limity prędkości, filtry geo/IP, flagi funkcji.

Warstwa serwisowa: autonomiczne mikroservice według domeny; umowy synchroniczne - tylko wtedy, gdy potrzebna jest natychmiastowa spójność (np. debet portfelowy na zakładzie).

Autobus imprezowy: główne wydarzenia biznesowe ("bet. placed", "round. settled ',' bonus. wydane „,” kyc. zweryfikowane „,” wypłata. wnioskowane ").

Dane: OLTP (Postgres/MySQL) dla transakcji; KV/Cache (Redis) dla sesji/limitów; przechowywanie obiektów (S3) do rejestrów i wywozu; OLAP (ClickHouse/اQuery) dla analityki.

3) Portfel i księga: serce platformy

Zasady:

Księga tylko dla użytkownika: każda transakcja finansowa jest zapisem typu, kwoty, waluty, odniesienia do źródła (stopa, bonus, depozyt).
Gotówka i salda bonusowe są wysyłane. Nie można „mieszać” pieniędzy i bonusów; wykorzystuje politykę źródeł finansowania.
Atomicity of debet → kredit: rate = debit of money or bonus portfel + creation of hold; runda kalkulacji usuwa hold i sprawia, że kredyt/debet na wynik.

Przykład transakcji kursowych:

„LEDGER: HOLD” (− 10. 00 EUR, źródło: gotówka, ref: betId)
"LEDGER: SETTLE_DEBIT' (− 10. 00 EUR) + „LEDGER: WYPŁATA” (+ 36. 00 EUR) - jeżeli WIN
"LEDGER: HOLD_RELEASE' (+ 10. 00 EUR) - jeżeli VOID/PUSH

Wymagania:

Operacje idempotentne (klucze idempotencji przez 'keyId').
Optymalne blokowanie w celu ochrony przed wyścigami.
Jasne obliczanie walut i ustalanie kursów konwersji.

4) Integracja z dostawcami gier

Wzory portfela:

Bez szwu - równowaga operatora; zakład/rozrachunek przechodzi przez nasz interfejs API w czasie rzeczywistym.
Przelew - depozyt do banku gier od dostawcy; więcej tarcia, ale niższy wymagany czas uptime torebki.

Ścieżki synchroniczne (krytyczne):

'bet. umieścić '→ pre-auth w portfelu (hold) →' accepted/rejected '.

Asynchroniczne ścieżki:

"teren. settle 'od dostawcy (webhook/WS) → rozliczyć się w księdze → wydarzenie do autobusu → raportowanie/premie.

Standaryzacja za pomocą mostu: jednolite schematy zdarzeń i identyfikatory ' Id/betId', tabela mapowania limitów i zakłady boczne, normalizacja błędów.

5) Bonusy, zakłady i przeciwdziałanie nadużyciom

Modele: bonusy depozytowe, freespins, zwroty (cashback), misje, turnieje.

Zakłady: obstawianie postępów przechowywane oddzielnie; Reguła „jakie zakłady liczą” (procenty według kategorii gry).

Kolejność odpisów: najpierw fundusze bonusowe, potem prawdziwe - lub odwrotnie, ściśle zgodnie z zasadami.

Anty-wzorce gracza: zakłady na przeciwstawne wyniki, minimalne zakłady na postęp gospodarstwa, transfer między grami o różnych ciężarach - złapany przez zasady i punktacji.

6) KYC/AML/KYT (RG)

KYC: identyfikator/adres/weryfikacja wieku; limity kontroli statusów (depozyt/wewnątrz/betMax).

AML/KYT: kontrola kanałów płatniczych i adresów pokładowych (do krypty), list sankcji, źródeł funduszy.

RG: dzienne/tygodniowe limity, terminy, samodzielne wykluczenie; kontrole blokowania są wykonywane przed 'bet. miejsce 'б' payout. wniosek ".

7) Środki pieniężne: depozyty i płatności

Depozyty: dostawcy kart/AWS, krypto/stajnie, metody lokalne; potwierdzenia haka internetowego; ochrona przed ryzykiem obciążenia zwrotnego.

Płatności: kolejki, limity, zasada 4-oka dla dużych kwot; źródła funduszy → „tylko saldo gotówki”.

Na rampie/poza rampą krypty: automatyczna konwersja, adresy KYT, zabezpieczenie ekspozycji.

8) Limity, przepisy dotyczące ryzyka i zasady regionalne

Profile graniczne ('DEFAULT', 'VIP _ A', 'VIP _ B', 'ULTRA') według kraju/waluty/ACC.

Blokowanie geograficzne przez IP/GPS/document.

Pokrywa się według gry/kategorii, dostawca zakazuje w jurysdykcjach.

Reakcja na anomalie: wybuchy zakładów, korelacja urządzeń/płatności, dużo „VOID” od jednego użytkownika.

9) Obserwowalność i działanie

Metryki: opóźnienia portfela, niepowodzenie zakładu, czas obliczenia okrągłego, depozita → konwersja stavka, GGR/NGR, wypłata SLA, udział w zakładach bonusowych.

Kłody i ślady: korelacja "traceId' we wszystkich zdarzeniach; przechowywanie nieprzetworzonych zdarzeń w „chłodnym” magazynie.

Alerty: degradacja odpowiedzi portfela, skok „VOID”, pogodzić błąd raportu, wzrost „RG _ BLOCKED”.

Runbooks: przejrzyste procedury incydentów (spadek dostawcy, rejestr z synchronizacji, rundy anulowane).

10) Bezpieczeństwo i prywatność

Auth: krótkotrwałe żetony JWT/nieprzezroczyste, rotacja klucza („dziecko”), mTLS do integracji krytycznych.

Polityka dostępu: ścisłe rozdzielenie ról (operacje, finanse, wsparcie), 2FA; za duże płatności - w porządku od drugiej osoby.

Prywatność danych: szyfrowanie PII, tokenizacja danych płatniczych, minimalizacja przechowywania; RODO/usunięcie na żądanie.

Audyt: niezmienne dzienniki, podpis zdarzeń krytycznych, eksport dla regulatora.

11) Skalowalność i tolerancja uszkodzeń

Usługi statles za automatycznym skalerem; poziomy odłamek dla gorących tabel (stawki, dzienniki zdarzeń).

Księga - margines pionowy + replikacja do odczytu/raportowania; „zamrożenie” systemów migracji poprzez tablice cieni.

Buforowanie: Redis ze strategiami TTL i „two-check” (odczytanie + unieważnienie przez zdarzenia).

DR/HA: multi-AZ, kopie zapasowe z regularnym odzyskiem, RPO/RTO na poziomie wymagań regulacyjnych.

Tryby degradacji: autonomiczna realizacja transakcji, wyłączanie „ciężkich” bonusów, przenoszenie gier na żywo do konserwacji, gdy autobus jest niedostępny.

12) Umowy i przykłady

Zakład (synchronizacja, JSON/REST lub gRPC):

json
POST/zakłady/miejsce
{
" " "portfel": "9a7f-"..., "plaاId':"  ":" gotówka ",
"roundId':" R-2025-10-17-19:20:05-PRAGM-Table12, "" gameId': "pragm_live_roulette," "wybór": [{"rynek": "prosty", "wartość": "17"}], "stawka": {"kwota": "10. 00 „, „waluta”:” EUR”}, „urządzenie”: {„ip „:” 203. 0. 113. 5 ", "ua ": "Mozilla/"..}
}

Odpowiedź:

json
{
„status”: „PRZYJĘTY”, „betId':” bet_8cd..., „” Po „:” 245. 30”, „hold”: „10. 00 "," limity ": {" maxBet': "5000. 00"}
}

Wydarzenie autobusowe (async):

json
{
"event ":" runda. settled „,” roundId': „R-2025-10-17-19: 20: 05-PRAGM-Table12”, „bets': [{” betId': „bet _ 8cd'...,” result „:” WIN „,” stake „:” 10. 00 „, „wypłata”:” 360. 00 "}], odtwarzacz Id':" p _ 123 "," ts': "2025-10-17T19: 20:09. 231Z, „” traceId': „tr _ 5f1”..
}

13) Anty-wzory (co łamie platformę)

Wymieszaj bonus i gotówkę w pojedynczej transakcji bez źródeł.

Długotrwałe żetony i przechowywanie ich na kliencie.

Brak idempotencji w operacjach krytycznych (debet podwaja się).

Monolityczne raportowanie SQL dla bazy danych walki (OLAP kontra OLTP).

Niewidomy pełnomocnictwo do dostawcy bez pogodzenia i ograniczenia.

Brak standardu strefy czasowej (UTC wszędzie!) w okrągłych identyfikatorach i raportach.

Połączenia synchroniczne w domenach niefinansowych (bonusy/powiadomienia) blokują zakład.

14) Lista kontrolna uruchomienia backendu kasyna

Finanse i portfel

Tylko księga, idempotencja, wersja bilansu.
Separacja środków pieniężnych/premii, polityka źródłowa.
Stawki/konwersje są zapisywane w transakcji.

Integracja gier

Umowa o jednolitą stawkę/rozrachunek, format "roundId/betId'.
Domyślnie portfel bez szwu; Przeniesienie - tylko w uzasadnionych przypadkach.
Automatyczne skrypty VOID/REFUND.

KYC/AML/RG

Zasady przed dopuszczeniem do stawki/wynagrodzenia; Statusy KYC
KYT dla łańcucha, kontroli sankcji, przechowywania dowodów.

Biurko kasowe

Haki/podpisy, podwójne/przekładki, zgadzają się z dostawcami PSP/crypto.
4-oglądanie dużych wypłat, dziennik aktywności operatora.

Obserwowalność

Mierniki portfela, opóźnienie w rozliczeniu okrągłym, niepowodzenie w ofercie, wypłata SLA.
Ślady to end-to-end (traceId), wpisy, książki startowe.

Bezpieczeństwo

mTLS/HMAC, JWT z krótkim TTL, rotacja klucza.
Role/prawa, 2FA, tokenizacja danych dotyczących płatności.

Dane

Separacja OLTP/OLAP, CDC do DWH, S3 dla zdarzeń surowych.
Kopie zapasowe i regularne testy odzysku.

15) Najważniejsze

Architektura kasyna backend jest ścisłym rdzeniem pieniędzy i zakładów z liniową spójnością i elastycznymi peryferiami na wydarzeniach: bonusy, analityka, komunikacja. O sukcesie decyduje nie liczba mikroservices, ale dyscyplina: wyraźne granice domeny, księga bez „magii”, idempotencja, obserwowalność i domyślna zgodność. Dzięki tej fundacji platforma skaluje się w różnych krajach/walutach/dostawcach i wytrzymuje obciążenia bez kompromisów w zakresie bezpieczeństwa i pieniędzy.