IGamingのREST、 gRPC、 Webhook：パターンとアンチパターン

完全な記事

💡 18+.iGaming製品およびエンジニアリングチームの技術資料。再生する呼び出しではありません。「プラットフォーム」とは、PAM/ウォレット/レジ/ボーナス/RGを意味します。「プロバイダー」-RGS/ライブ/ジャックポット/アグリゲーター。

1）プロトコルマップ： 誰が何を担当しているか

REST-HTTP/JSON経由のユニバーサル同期リクエスト。透明なキャッシュ、簡単なデバッグ、B2B統合と管理APIに便利です。

gRPC-HTTP/2上の高性能バイナリRPC：低遅延、ストリーム、ハード回路。ホットマネーパス（ウォレット/セトル）、社内サービス、長寿命ストリーム（ライブ）に適しています。

Webhookは受信者から送信者へのコールバックです。イベント（「お金が落ちた」「、限界が働いた」）に使用されます。イニシエータは常に結果を待っている人ではありません。

ゴールデンルール：

お金は、ハードインバリアントとidempotencyと同期RPC （REST/gRPC）になります。テレメトリーとビジネスイベント-非同期（webhooks+event bus）。

2）典型的なパスおよび推薦されたチャネル

ウェイ（Way）	おすすめです	どのような理由で
'bets。authorize'（ホールド）	gRPC（内部）/REST （B2B）	最小限のレイテンシ、厳密なSLA
'bets。settle'→'wallet。クレジット（クレジット）	gRPC同期+バスへのイベント	money=ACID；events=observability
「レジ係」入金/出金'	REST+idempotency	PSPとの統合、トレース
'RGチェック/停止'	gRPC/REST同期	ブレーキライトは即座に消えるべきです
「ボーナス」issue/consume'	REST同期	ビジネスロジック、適度なSLA
'jackpot。trigger/payout'	gRPC/REST+イベント	マネー契約+監査
テレメトリー、アナリティクス、アラート	Webhooks+バス（カフカ/パルサー）	持続可能性と規模
ライブステータス/ディレクトリ	gRPCストリーミング/サーバー送信イベント	世論調査とラグの最小化

3）契約指向の設計

3.1 REST（フラグメント）


POST/v1/bets/authorize
ヘッダー：X-Idempotency-Key： bet_r_8c12_1、 X-Trace-Id： tr_a1b2
{
「session_id":"s_456,」 「bet_id":"b_001,」 「round_id":"r_8c12,」「量「：{」量」：2。00、 「currency」：」 EUR」}
}
→200 {「status「：「authorized」、」 hold_id」：」 h_zz1」}

エラー（単一のスキーマ）：


409
{「code「：「DUPLICATE」、」 message」：」 Bet already authorized「、「retryable「：false」、 trace_id」：」 tr_a1b2」}

3.2 gRPC （protobuf、簡略化）

proto構文=「proto3」；
パッケージ財布。v1；

message Money {int64 minor_units=1；string currency=2；}//セントメッセージAuthorizeBetReq {string session_id=1；文字列bet_id=2；文字列round_id=3；金額=4。string idempotency_key=5；}
message AuthorizeBetRes {string status=1；string hold_id=2；}

サービスウォレット{
rpc AuthorizeBet （AuthorizeBetReq）戻り値（AuthorizeBetRes）；
rpc SettleBet （SettleReq）戻り値（SettleRes）；
}

3.3 Webhook（サブスクリプション例）


POST https：//プロバイダ。例/webhooks
{
"topic"："wallet。クレジットだ。""、"callback_url":"https://rgs。例/journal、""secret"："、"version"： "1。2"
}

配達：


POST https ：//rgs。例/ジャーナル
ヘッダー：X-Signature： sha256=……、X-Trace-Id： tr_a1b2
{
「event_type":"wallet。」クレジットだ。""、"schema_version":"1。2.0、""event_id":"uuid,""ペイロード"：{"player_id"："p_19f3"、"amount'： {"minor_units'： 1460"、 currency"："EUR"}}
}

4） Idempotencyおよび一貫性

書き込み操作（REST/gRPCメタデータ）には常に'X-Idempotency-Key'が必要です。リプレイ→同じ答え。

キー構成はビジネスパラメータ（例えば'bet_id+amount'）に関連付けられます。

長いプロセスのためのサガ（authorize→commit/lock→settle→credit）。

Outbox/CDC：イベントはトランザクションの近くでアトミックにキャプチャされ、外部に公開されます。

5）バージョン管理と互換性

REST-'/v1/……'+'Deprecation/Sunset '-heads；gRPC-'パッケージ財布。v1'；イベント-ボディ+スキーマレジストリの'schema_version'。

SemVer：マイナー-オプション/新しいエンドポイントフィールド；major-新しいパス/パッケージ、移行時のイベントの「二重文字」。

メジャーバージョンなしでは、通貨統計の意味を変更しないでください。

6）輸送の安全

すべてのS2SでmTLS；webhookの場合-body signature （HMAC/EdDSA）+タイムスタンプと有効性ウィンドウ。

スコープ制限（OAuth2 CC）とブランド/リージョンキーセグメンテーションごと。

ゼロトラスト：ネットワークポリシー、短命トークン、Vault/HSM、重要なアクションのWORM監査。

7）観察可能性およびSLO

REST、 gRPCメタデータ、 Webhookのエンドツーエンド'trace_id'。

メトリクス：p50/p95/p99レイテンシ、コードによるエラー率、スループット、ラグキュー。

SLO最小（ランドマーク）：

Wallet p95 '<150 ms' （Authorize/Settle）、 REST public B2B p95 '<300 ms'、 Webhooksは'<5 min' 99 percentile「、Lost/Duplicated Settlements」=0を配信した。

8） Retrai、バックオフおよび配達順序

REST/gRPC：指数関数バックオフ、ジッタ、期間制限（期限/タイムアウト）。

Webhooks： '2xx'への繰り返し可能な配達；キー（'player_id/round_id'）またはレシーバでの重複除外による順序の保持。

反嵐：平行後退限界、遮断器、率の限界。

9）統合パターン

パターンA： 「マネー同期、イベント非同期」

1.RGS→Wallet （gRPC/REST） 'authorize'→'settle/credit'。

2.並行して、'bet'が公開されます。バスにsettled'、プロバイダはwebhook領収書を受け取ります。

プラス：高速お金、観測性。マイナス：2つの輪郭が必要です。

パターンB： 「ストリーミングライブ」

gRPCストリーミングによるライブコア↔ブリッジ（テーブルのステータス、賭けウィンドウ）。

現金取引-個別の単一RPC；イベント-バス/webhooksで。

プラス：ライブステータスの遅延を最小限に抑えます。

パターンC： 「B2B public REST」

カタログ/ボーナス/アフィリエイト/レポート-カーソルページネーション、フィルタ、ETagのREST。

プラス：シンプルなパートナー統合。

10）反模様（赤い旗）

現金取引はWebhookを介してのみ（同期確認なし）。

「Idempotency-Key」→重複したデビット/クレジットはありません。

outbox/CDCをバイパスするイベントの発行（イベントは失われます）。

符号なし/タイムスタンプされたWebhook→置換。

「region/tenant」タグなしで、1つのチャネルに異なる地域のPII/moneyを混在させます。

Webhookの大きなバイナリペイロード（ブレイクレトレイとリミット）。

ゼロ劣化：webhookの秋は、お金の計算をブロックします。

締め切りなしとバックオフなしのgRPC-接続をスタック、リソースの枯渇。

11）チェックリスト

アーキテクト/プラットフォーム

idempotencyのgRPC/RESTによるお金、イベント-webhooks/bus。
すべてのマネーパス上のOutbox/CDC。
'/vN 'uスキーマレジストリ；廃止/日没プロセス。
mTLS+webhook署名；ブランド/地域ごとに秘密を守ります。
SLOダッシュボードp95/p99、エラー率、webhook-lag。
DR/xaoc-exercises：ダブルデリバリー、アウトオブオーダー、地域のダンプ。

プロバイダ/RGS

'X-Trace-Id'と'X-Idempotency-Key'を送信します。
バックオフと重複除外；Webhookを再配達する準備ができています。
契約バージョンを更新する。'Deprecation/Sunset'に反応します。
エラーコードと時間によるログ/メトリック。

12）鋭い場合のための小型解決

Safari/ITPおよびサードパーティの制限：money-ホスト（REST/gRPC）では、iFrameコンテンツは'postMessage'；iFrame以外のホストからのwebhook。

マルチブランド：タグ'tenant_id/brand_id/license'ヘッダーとイベント；keys/certificatesは別個のものです。

大きなバースト（トーナメント）：webhookの前に-DLQでバッファ/キュー；オーバーロード時-"no new sessions'/" pause non-core hooks"。

13） SLO指向アラートの例

財布だよ。p95> 150 ms 5 minを連続で承認します。

'DUPLICATE/IDEMPOTENCY_MISMATCH'エラー>0。10分で5％。

Webhook lag p99> 180 cテーマ'bet。 settled'。

Kafkaでの消費者の遅れ>30 'walletのためのs。「クレジット」

14）出金

iGamingのREST、 gRPC、 Webhookは交換可能な技術ではなく、同じオペレーティングモデルの一部です。

REST/gRPCは、低遅延、idempotency、厳密なSLAなどの通貨不変量によって保持されます。

Webhook/busは、イベント、テレメトリ、統合などの透明性とスケールを提供します。

outbox/CDC、 versioning、 signatures、 observabilityを追加し、お金が素早く安全に移動し、イベントが失われず、アップグレードが痛みを伴わないアーキテクチャを取得します。