多くのオペレーターにとって、インプレイベッティングはスポーツベッティング収益の70%超を占めます。それを支えるアーキテクチャは、毎秒数千件のオッズ変更を、整合性を保証しながら処理しなければなりません。
チャンピオンズリーグ準決勝の89分、ゴールが決まります。3ms以内にカジノプラットフォーム上の該当マーケットがすべて停止し、50ms以内に再計算されたオッズが420万の接続クライアントへ届きます。
この一連の処理に遅れが生じると裁定の余地が生まれ、目の利くベッターに数秒で突かれます。
アーキテクチャの起点は、スポーツデータプロバイダーからのフィードです。プレーごとのイベント、統計の更新、事前計算されたオッズがWebSocket接続で届きます。
複数のゲームプロバイダーのフィードは、同じイベントをそれぞれ異なるレイテンシ、フォーマット、信頼性で配信します。フィードハンドラーに求められるのは次の点です:
フィードの正規化は、ライブベッティングのパイプラインで最初のボトルネックです。ここでの10msの遅延は、下流のすべてのシステムへ波及します。
スポーツベッティングエンジンは、レイテンシ予算の範囲内で数千のマーケットを同時に更新しなければなりません。純粋なリアルタイム計算では間に合いません。
この量をさばくにはハイブリッドな方式を採ります:
残り15%の更新はリアルタイムモデルを通ります。プレイヤー体験は、両方の経路が同じレイテンシの枠内で応答できるかにかかっています。
ゴールやレッドカードが出た瞬間、影響を受けるすべてのマーケットを即座に停止する必要があります。100msの遅れでも、目の利くベッターが見つけるアービトラージの隙が生まれます。
イベント駆動アーキテクチャは、専用の高優先度チャネルを通じて停止シグナルを伝播させます:
マーケットのサスペンドはレイテンシを一切許容しません。機能ではなく安全機構だからです。
更新のたびに数百万の接続クライアントへオッズの全スナップショットを配信すれば、どのようなネットワークも飽和します。差分圧縮により帯域を85-95%削減します。
クライアント側のレンダリングパイプライン:
試合中にWebSocketが切断されても、ベットスリップが失われてはなりません。プレイヤー管理システムは、プレイヤーセッションに紐づけてベットスリップの状態をサーバー側で保持します。
チャンピオンズリーグ決勝では、モバイル利用者がWiFiとセルラーを行き来するため再接続率が急増します。セッション層はその負荷を吸収しなければなりません:
入金上限、セッションタイマー、負け追い検知は、ゲーム体験を損なうことなくライブベッティングのパイプライン内で動作します。
ブロッキングチェック(入金上限、自己排除の状態)はインメモリキャッシュから読み取り、2ms未満で完了します。行動スコアリングはイベントストリーム上で非同期に実行し、プレイヤーの嗜好とベットパターンから問題行動の兆候を分析します。
ライブディーラーゲームとオンラインカジノゲームは、同じカジノプラットフォーム上で共通のアーキテクチャパターンを持ちます。リアルタイムのイベント処理、即時の状態伝播、そしてプレイヤー体験に体感できる遅延を加えないコンプライアンスチェックの統合です。
iGaming業界では、ピーク時のイベント中も、責任あるゲーミングの基盤がベッティングエンジンと同じようにスケールすることが求められます。処理が追いつかないコンプライアンス基盤は、性能上の問題ではなく規制上のリスクです。
現在のアーキテクチャと気になっている障害シナリオをお持ちください。30 分で一緒に確認します。