カジノバックエンドアーキテクチャの仕組み

1）全体像： ドメインおよびデータストリーム

主なドメイン：

IDとアカウント-登録、認証、ロール、デバイス、セッション。
ウォレット&元帳-現金口座、ボーナスウォレット、トランザクション、元帳（追加のみ）。
ゲーム&ベット-ゲームセッション、ベット、ラウンド、結果の計算、統合（RNG/ライブ/クラッシュなど）。
ボーナス&プロモーション-フリースピン、キャッシュバック、バウチャー、賭け（賭け）、反乱用。
支払い（キャッシャー）-オンランプ/オフランプ：マップ、APM、 crypt/stablecoins、 KYCバインディング。
KYC/AML/KYT&RG-アイデンティティ/アドレス/収益検証、トランザクションスクリーニング、制限とタイムアウト。
リスクとコンプライアンス-レート/支払いの制限、制裁リスト、地理的ブロック、監査。
カタログ&ロビー-プロバイダ、ゲーム、カテゴリ、制限のリスト。A/Bバリアント。
レポート&BI-P&L、 GGR/NGR、リテンション、プレーヤーのライフサイクル、アフィリエイト。
オブザベーション&Ops-ログ、メトリクス、トレース、アラート、詐欺信号。

オーケストレーション：最新のプラットフォームはイベント駆動型で構築されています。バス（Kafka/NATS）を介したサービス交換イベント、重要な操作は線形化（ウォレット/レジャー）、サイドサブシステムは非同期に署名され応答されます（ボーナス、BI、通知）。

2）レイヤードモデル

エッジレイヤー：APIゲートウェイ、WAF/ボット保護、レート制限、geo/IPフィルタ、フィーチャーフラグ。

サービス層：ドメインごとの自律マイクロサービス；同期コントラクト-インスタント一貫性が必要な場合のみ（例：ベット時にウォレットデビット）。

イベントバス：主なビジネスイベント（'bet。 placed'、 'round。決済'、'ボーナス。'、'kycを発行しました。検証された'、'ペイアウト。要求された'）。

データ：取引のためのOLTP （Postgres/MySQL）；セッション/制限のKV/キャッシュ（Redis）；ログとエクスポートのオブジェクトストレージ（S3）；分析のためのOLAP （ClickHouse/BigQuery）。

3）財布と台帳： プラットフォームの中心

原則：

追加のみの元帳：各金融取引は、種類、金額、通貨、ソースへの参照（レート、ボーナス、預金）のレコードです。
現金とボーナス残高を掲載しています。お金とボーナスを「混ぜる」ことはできません。資金源ポリシーを使用しています。
debet→kreditのatomicity： rate=debit of money or bonus wallet+creation of hold；ラウンド計算はホールドを削除し、結果にクレジット/デビットを行います。

レートトランザクションの例：

'LEDGER： HOLD' （− 10。00 EUR、ソース：現金、参照：betId）
'LEDGER： SETTLE_DEBIT' （− 10。00 EUR）+'LEDGER： PAYOUT'（+36。00 EUR）-WINの場合
'LEDGER： HOLD_RELEASE'（+10。00 EUR）-VOID/PUSHの場合

要件：

Idempotent操作（'requestId'によるidempotenceキー）。
レースから保護するための最適なロック。
コンバージョンのための明確な計算通貨と固定レート。

4）ゲームプロバイダーとの統合

ウォレットパターン：

シームレス-オペレータのバランス；ベット/決済はリアルタイムで当社のAPIを通過します。
送金-プロバイダからゲームバンクへの入金。より多くの摩擦、しかしより低い財布の稼働時間の条件。

同期パス（クリティカル）：

'ベット。place'→pre-auth in the wallet （hold）→'accepted/rejected'。

非同期パス：

「ラウンド」settle'プロバイダから（webhook/WS）→レジャーにsettle→バス→レポート/ボーナスへのイベント。

ブリッジによる標準化：均一なイベントスキーマと'roundId/betId'識別子、マッピングテーブルとサイドベットの制限、エラー正規化。

5）ボーナス、賭け、乱用防止

モデル：預金ボーナス、フリースピン、リターン（キャッシュバック）、ミッション、トーナメント。

賭け：別に貯えられる賭けの進歩；「ベット数」ルール（ゲームカテゴリ別のパーセンテージ）。

書き込みの順序：最初のボーナス資金、その後、実際-またはその逆、厳密にポリシーに従って。

プレーヤーのアンチパターン：反対の結果に賭け、農場の進歩のための最低ベット、異なる重みを持つゲーム間の転送-ルールと得点によってキャッチ。

6） KYC/AML/KYT○責任あるゲーム（RG）

KYC： ID/住所/年齢検証；ステータス制御制限（deposit/in/betMax）。

AML/KYT：決済チャネルとチェーンアドレスのスクリーニング（crypt用）、制裁リスト、資金源。

RG： 毎日/毎週の限界、タイムアウト、自己排除；ブロックのチェックは'bet'の前に行われます。「ペイアウト」を配置します。「リクエスト」

7）現金： 預金と支払い

預金：カード/AWSプロバイダ、暗号/ステーブル、ローカルメソッド；webhookの確認；チャージバックのリスクに対する保護。

支払： 大量のためのキュー、限界、4目の原則；資金源→「現金残高のみ」

オンランプ/オフランプ暗号：自動変換、KYTアドレス、露出ヘッジ。

8）制限、リスク、地域ルール

プロファイル（'DEFAULT'、 'VIP_A'、 'VIP_B'、 'ULTRA'）を国/通貨/ACCで制限します。

IP/GPS/ドキュメントによるジオブロッキング。

ゲーム/カテゴリ別の重複、管轄区域のプロバイダーの禁止。

異常に対する反応：賭けのバースト、デバイス/支払いの相関、1人のユーザーからの多くの「VOID」。

9） Observabilityおよび操作

メトリクス：ウォレット遅延、ベット失敗、ラウンド計算時間、depozita→stavka変換、GGR/NGR、 SLAペイアウト、ボーナスベットのシェア。

ログとトレース：すべてのイベントにおける相関'traceId'；「冷たい」貯蔵の未加工でき事の貯蔵。

アラート：ウォレット応答の劣化、'VOID'スパイク、レポートエラーの調整、'RG_BLOCKED'の増加。

Runbooks：明確なインシデントプロシージャ（プロバイダのドロップ、同期からの元帳、ラウンドのキャンセル）。

10）セキュリティとプライバシー

Auth：短命なJWT/不透明なトークン、キー回転（'kid'）、重要な統合へのmTLS。

アクセスポリシー：役割の厳密な分離（業務、財務、サポート）、2FA；大きな支払いのために-2人目からOK。

データプライバシー：PII暗号化、支払いデータのトークン化、ストレージの最小化；リクエストに応じてGDPR/削除。

監査：変更不能なログ、重要なイベントの署名、レギュレータのエクスポート。

11）スケーラビリティとフォールトトレランス

オートスケーラーの背後にあるStatlesサービス。ホットテーブルの水平シャード（レート、イベントログ）。

元帳-読み取り/レポート用の垂直マージン+レプリケーション。シャドウテーブルを介した「フリーズ」移行スキーム。

キャッシュ：TTLと「Two-check」戦略によるRedis（イベントによって読み取りスルー+無効）。

DR/HA：マルチAZ、定期的なリカバリを伴うバックアップ、規制要件のレベルでのRPO/RTO。

劣化モード：自動チェックアウト、「重い」ボーナスを無効にし、バスが利用できないときにライブゲームをメンテナンスに転送します。

12）契約と例

ベット（同期、JSON/RESTまたはgRPC）：

json
POST/ベット/場所
{
「requestId」： 「9a7f-……」、 「playerId」： 「p_123,」 「wallet」： 「cash」、
「roundId」： 「R-2025-10-17-19:20:05-PRAGM-Table12,」 「gameId」： 「pragm_live_roulette,」 「selection」： ［{「market」： 「straight」、 「value」： 「17」}］、 「stake」： {「amount'：」 10。00、 「「currency」：」 EUR」}、 「device」： {「ip「：」203。0.113.5"、"ua"："Mozilla/"……}
}

答え：

json
{
"status"： "ACCEPTED"、 "betId"： "bet_8cd...," "balanceAfter"： "245。30」「、ホールド」：「10。00、 「limits'：{」maxBet「：」5000。00"}
}

バスイベント（非同期）：

json
{
"event"："round。決済、""roundId"："R-2025-10-17-19： 20： 05-PRAGM-Table12"、"bets'： ［{"betId"： "bet_8cd……"、"結果"："WIN"、 "stake"： "10。00「、「payout」：」 360。00「}］、「playerId」：」 p_123」、 「ts「：」2025-10-17T19： 20：09。231Z," "traceId"："tr_5f1"……
}

13）反パターン（プラットホームを壊す）

ソースのない単一のトランザクションでボーナスと現金をミックスします。

長寿命のトークンとクライアントに保存します。

重大な操作（デビット・ダブル）におけるidempotencyの欠如。

戦闘データベース用のモノリシックなレポートSQL （OLAPとOLTP）。

調和し、限界なしで提供者への代理人の盲目の力。

タイムゾーン標準なし（UTCどこでも！）丸い識別子とレポート。

非財務ドメインの同期コール（ボーナス/通知）は、ベットをブロックします。

14）カジノバックエンド起動チェックリスト

財務・財布

Ledger append-only、 idempotency、 balance version。
現金/ボーナスの分離、ソースポリシー。
レート/コンバージョンはトランザクションでキャプチャされます。

ゲームインテグレーション

シングルレート/決済契約、'roundId/betId'形式。
デフォルトでシームレスウォレット。転送-正当化された場合のみ。
自動VOID/REFUNDスクリプト。

KYC/AML/RG

料金/支払に入学する前のポリシー。KYCのステータス↔制限。
オンチェーン、制裁スクリーニング、証拠保管のためのKYT。

キャッシュデスク

Webhooks/signatures、 doubles/retray、 PSP/暗号プロバイダとの調整。
大規模な支払い、オペレータの活動ログに4目。

観測可能性

ウォレットのメトリック、ラウンドセットルレイテンシー、入札失敗、ペイアウトSLA。
トレースはエンドツーエンド（traceId）、アラート、ランブックです。

安全性について

mTLS/HMAC、短いTTLのJWT、キー回転。
役割/権利、2FA、支払いデータのトークン化。

データ

OLTP/OLAP分離、CDCからDWH、 rawイベントのS3。
バックアップと定期的なリカバリテスト。

15）ボトムライン

バックエンドカジノアーキテクチャは、ボーナス、アナリティクス、コミュニケーションなど、イベントにおけるリニアな一貫性と柔軟な周辺機器を備えた、お金と賭けの厳密なコアです。成功はマイクロサービスの数によってではなく、規律によって決定されます。明確なドメイン境界、「魔法」のない元帳、idempotency、オブザビリティ、コンプライアンスのデフォルトです。この基盤により、プラットフォームは国/通貨/プロバイダーを横断し、セキュリティとお金に妥協することなく負荷に耐えます。