토렌트 기어

카지노 백엔드 아키텍처 작동 방식

1) 전체 그림: 도메인 및 데이터 스트림

주요 도메인:

신원 및 계정-등록, 인증, 역할, 장치, 세션.
지갑 및 원장-현금 계좌, 보너스 지갑, 거래, 원장 (추가 전용).
게임 및 베팅-게임 세션, 베팅, 라운드, 결과 계산, 통합 (RNG/Live/Crash 등).
보너스 및 프로모션-프리 스핀, 캐쉬백, 바우처, 베팅 (베팅), 남용 방지.
지불 (캐시어) -온 램프/오프 램프: 맵, APM, 크립트/스 테이블 코인, KYC 바인딩.
KYC/AML/KYT & RG-신원/주소/수익 검증, 거래 심사, 제한 및 시간 초과.
위험 및 준수-요율/지불 제한, 제재 목록, 지리 차단, 감사 제한.
카탈로그 및 로비-제공자, 게임, 카테고리, 한계 목록; A/B 변형.
보고 및 BI-P & L, GGR/NGR, 보존, 플레이어 수명주기, 계열사.
관찰 및 작전-로그, 지표, 흔적, 경고, 사기 신호.

오케스트레이션: 최신 플랫폼이 이벤트 중심으로 구축됩니다: 버스를 통한 서비스 교환 이벤트 (Kafka/NATS), 중요 운영이 선형화 (지갑/원장), 사이드 서브 시스템에 서명 및 응답 (보너스, BI, 알림).

2) 레이어 모델

에지 레이어: API 게이트웨이, WAF/봇 보호, 속도 제한, 지리/IP 필터, 기능 플래그.

서비스 층: 도메인 별 자율 마이크로 서비스; 동기 계약-즉각적인 일관성이 필요한 경우에만 (예: 내기시 지갑 직불 결제).

이벤트 버스: 주요 비즈니스 이벤트 ('bet. place', 'round. ',' 보너스를 정산했습니다. ', kyc. 확인 된 ',' 지불. 요청 ').

데이터: 트랜잭션을위한 OLTP (Postgres/MySQL); 세션/제한에 대한 KV/캐시 (Redis); 로그 및 내보내기위한 객체 저장 (S3); 분석을위한 OLAP (ClickHouse/Bigquery).

3) 지갑 및 원장: 플랫폼의 핵심

원칙:

추천 전용 원장: 각 금융 거래는 유형, 금액, 통화, 소스에 대한 참조 (요율, 보너스, 예금) 가있는 레코드입니다.
현금 및 보너스 잔액이 게시됩니다. 돈과 보너스를 "혼합" 할 수 없습니다. 자금 출처 정책을 사용합니다.
debet → kredit의 원자: rate = 자동 이체 또는 보너스 지갑 + 보류 생성; 라운드 계산은 홀드를 제거하고 결과에 대한 크레딧/직불 결과를 만듭니다.

요율 거래의 예:

'LEDGER: HOLD' (-10. 00 EUR, 출처: 현금, 심판: betid)
'LEDGER: SETTLE _ DEBIT' (-10. 00 EUR) + 'LEDGER: PAYOUT' (+ 36. 00 EUR) -승리 한 경우
'LEDGER: HOLD _ RELEASE' (+ 10. 00 EUR) -VOID/PUSH 인 경우

요구 사항:

이데올로기 작업 ('요청' 에 의한 deimpotence 키).
경주로부터 보호하기위한 최적의 잠금.
계산 통화를 지우고 변환 요금을 수정하십시오.

4) 게임 제공 업체와의 통합

지갑 패턴:

원활한-운영자의 균형; 베팅/정산은 실시간으로 API를 통과합니다.
양도-공급자로부터 게임 뱅크로 예금; 더 많은 마찰이지만 지갑 가동 시간 요구 사항은 낮습니다.

동기식 경로 (중요):

'내기. 지갑에 '→ 사전 정의 (보류) →' 허용/거부 '

비동기 경로:

'라운드. 공급자 (webhook/WS) 에서 해결 → 원장 → 버스 이벤트 → 보고서/보너스에 해당합니다.

브리지를 통한 표준화: 균일 한 이벤트 스키마 및 '원형/베트' 식별자, 제한 매핑 테이블 및 사이드 베팅, 오류 정규화.

5) 보너스, 베팅 및 남용 방지

모델: 예금 보너스, 프리 스핀, 반품 (캐쉬백), 미션, 토너먼트.

Wagering: 별도로 저장된 베팅 진행 상황; "베팅 계산" 규칙 (게임 카테고리 별 백분율).

상각 순서: 정책에 따라 엄격하게 첫 번째 보너스 자금, 실제 또는 그 반대입니다.

플레이어의 반 패턴: 반대 결과에 베팅, 농장 진행에 대한 최소 베팅, 다른 무게를 가진 게임 간 전송-규칙에 따라 잡히고 득점.

6) KYC/AML/KYT... 책임있는 게임 (RG)

KYC: ID/주소/연령 확인; 상태 제어 한계 (예금/내부/betMax).

AML/KYT: 결제 채널 및 체인 주소 (토굴 용), 제재 목록, 자금 출처 심사.

RG: 일일/주간 제한, 타임 아웃, 자기 배제; 차단 검사는 'bet 전에 수행됩니다. 'nbsp;' 지불금을 주세요. 요청 '.

7) 현금: 예금 및 지불

예금: 카드/AWS 제공 업체, 암호화/마구간, 현지 방법; 웹 후크 확인; 청구 위험으로부터 보호합니다.

지불: 대량 대기열, 한계, 4 눈 원리; 자금 출처 → "현금 잔액 만".

온 램프/오프 램프 지하실: 자동 변환, KYT 주소, 노출 헤징.

8) 한계, 위험 및 지역 규칙

국가/통화/ACC별로 프로필 ('DEFAULT', 'VIP _ A', 'VIP _ B', 'ULTRA') 을 제한합니다.

IP/GPS/문서에 의한 지리 차단.

게임/카테고리별로 겹치면 공급자는 관할 구역에서 금지됩니다.

이상에 대한 반응: 베팅의 버스트, 장치/결제의 상관 관계, 한 사용자의 많은 "VOID".

9) 관찰 및 운영

지표: 지갑 지연, 내기 실패, 라운드 계산 시간, depozita → stavka 변환, GGR/NGR, SLA 지불, 보너스 베팅 공유.

로그 및 추적: 모든 이벤트에서 상관 관계 'traceID'; "콜드" 스토리지의 원시 이벤트 저장.

경고: 지갑 응답 저하, 'VOID' 스파이크, 보고서 오류 조정, 'RG _ BLOCKED' 성장.

런북: 명확한 사고 절차 (공급자 삭제, 원장 동기화, 라운드 취소).

10) 보안 및 개인 정보 보호

Auth: 수명이 짧은 JWT/불투명 한 토큰, 키 회전 ('kid'), mTLS에서 중요한 통합까지.

접근 정책: 역할의 엄격한 분리 (운영, 재무, 지원), 2FA; 큰 지불을 위해-두 번째 사람으로부터 괜찮습니다.

데이터 프라이버시: PII 암호화, 결제 데이터 토큰 화, 스토리지 최소화; 요청시 GDPR/삭제

감사: 변경 불가능한 로그, 중요한 이벤트의 서명, 규제 기관 수출.

11) 확장 성 및 내결함

자동 스케일러 뒤에있는 상태 서비스; 핫 테이블의 수평 파편 (속도, 이벤트 로그).

원장-읽기/보고를위한 수직 마진 + 복제; 섀도우 테이블을 통한 "동결" 마이그레이션 체계.

캐싱: TTL 및 "2 확인" 전략이있는 Redis (이벤트별로 읽기 + 무효화).

DR/HA: 다중 AZ, 정기적 인 복구 백업, 규제 요구 사항 수준의 RPO/RTO.

분해 모드: 자율 결제, "무거운" 보너스 비활성화, 버스를 사용할 수없는 경우 라이브 게임을 유지 보수로 전송합니다.

12) 계약 및 예

내기 (동기화, JSON/REST 또는 gRPC):

json
POST/베팅/장소
{
"요청자": "9a7f-"..., "플레이어": "p _ 123", "지갑": "현금",
"원형": "R-2025-10-17-19: 20: 05-PRAGM-Table12", "gameID": "fragm _ live _ 룰렛", "선택": [{"market": "straight", "값": "17"}], "스테이크": {"금액": "10. 00, "" 통화 ":" EUR "}," 장치 ": {" ip ":" 203. 0. 113. 5, "" ua ":" 모질라/"..}
}

답변:

json
{
"상태": "ACCEPTED", "betID": "bet _ 8cd"..., "balanceAfter": "245. 30, "" 보류 ":" 10. 00 "," 한계 ": {" maxBet ":" 5000. 00"}
}

버스 이벤트 (async):

json
{
"이벤트": "라운드. "라운드": "R-2025-10-17-19: 20: 05-PRAGM-Table12", "베팅": [{"betID": "bet _ 8cd"..., "결과": "WIN", "스테이크": "10. 00 "," 지불 ":" 360. 00 "}]," playerID ":" p _ 123 "," ts ":" 2025-10-17T19: 20:09. 231Z "," traceID ":" tr _ 5f1 "...
}

13) 반 패턴 (플랫폼을 파괴하는)

소스가없는 단일 거래에서 보너스와 현금을 혼합하십시오.

수명이 긴 토큰과 클라이언트에 저장합니다.

중요한 작업에서 demotency 부족 (직불 복식).

전투 데이터베이스 용 모 놀리 식보고 SQL (OLAP 대 OLTP).

화해와 제한없이 제공자에게 변호사의 맹인 권한.

시간대 표준 없음 (UTC!) 원형 식별자 및 보고서에서.

비재무 도메인 (보너스/알림) 의 동기식 통화로 베팅이 차단됩니다.

14) 카지노 백엔드 실행 체크리스트

금융 및 지갑

원장 추가 전용, demempotency, 밸런스 버전.
현금/보너스 분리, 소스 정책.
요금/변환은 거래에서 캡처됩니다.

게임 통합

단일 요율/결제 계약, 'roundID/betID' 형식.
기본적으로 완벽한 지갑; 양도-정당한 경우에만.
자동 VOID/REFUND 스크립트.

KYC/AML/RG

요율/지불 입학 전 정책; KYC 상태 표시줄 한계.
온 체인, 제재 심사, 증거 저장을위한 KYT.

현금 데스크

웹 후크/서명, 복식/복귀, PSP/암호화 제공 업체와 조정.
큰 지불금에 대한 4 눈, 운영자 활동 로그.

관찰 가능

월렛 메트릭, 라운드 정착 대기 시간, 입찰 실패, 지불 SLA.
흔적은 엔드 투 엔드 (traceID), 경고, 런북입니다.

안전

mSL/HMAC, 짧은 TTL, 키 회전의 JWT.
역할/권리, 2FA, 지불 데이터 토큰 화.

데이터

원시 이벤트에 대한 OLTP/OLAP 분리, CDC-DWH, S3.
백업 및 정기적 인 복구 테스트.

15) 결론

백엔드 카지노 아키텍처는 보너스, 분석, 커뮤니케이션 등 이벤트에 대한 선형 일관성과 유연한 주변 장치를 갖춘 엄격한 자금 및 베팅의 핵심입니다. 성공은 마이크로 서비스의 수가 아니라 훈련에 의해 결정됩니다: 명확한 도메인 경계, "매직" 이없는 원장, demempotency, 관찰 및 기본적으로 준수. 이 기초를 통해 플랫폼은 국가/통화/공급자에 걸쳐 확장되며 보안 및 돈에 대한 타협없이 부하를 견뎌냅니다.