メッセージブローカーとイベントルーティング

（セクション： 技術とインフラ）

概要

Message Brokerは、iGamingの統合とイベントバスの基本層です。レート、決済、不正防止、KYC、 CRM、分析のマイクロサービス間でのメッセージの配信、バッファリング、ルーティングを実装しています。よく設計された取引所（取引所）、キュー、ルーティングキー、再配達ルールは、低レイテンシー、トラフィックバーストに対する耐性、予測可能なSLOを提供します。

iGamingプラットフォームにおけるブローカーの役割

デカップリングサービス：ハード同期コールの代わりにイベントを発行します。
柔軟なルーティング：1つのイベント→多くの消費者（CRM、リスク、分析）。
ロード管理：キュー、プリフェッチ/QoS、バックプレッシャー。
信頼性とリカバリ：確認、リトレイ、DLQ、レプリケーション。
監査とコンプライアンス：イベントトレーシング、PIIマスキング、保持ポリシー。

メッセージングモデル

ポイントツーポイント（タスクキュー）：1つの消費者がタスク（KYC、電子メール、PSP webhook）を処理します。
Pub/Sub（ドメインイベント）：複数のキューのファンアウトを使用して取引所に公開します。
ブローカーを介したRPC：相関を持つリクエスト/レスポンス（ホットパスではまれですが、統合には便利です）。

ルーティングコンセプト（AMQP Classics）

取引所とバインディングは、メッセージがどのキューに入るかを決定します：

1.ダイレクト-'routing_key'の正確なマッチ。

2.topic-templates 'a。b。c 'c "（1つの単語）と'#'（0+words）。普遍的な選択。

3.fanout-関連するすべてのキューにブロードキャストします。

4.headers-ヘッダルーティング（キー/値）。複雑なポリシーに役立ちます。

キーとトポロジーの例：

「支払い」psp。ストライプ。成功しました。psp。。 failed'、'ベット。生きています。#'、'rg。限界。「違反」
ドメイン別の取引所：'支払い。トピック'、'賭け。トピック'、'リスク。トピック'；個別-'プラットフォーム'システムイベント。「監査」。

推奨事項：

ドメインキースキームを標準化します。サブドメイン。動詞。status'（ヘビ）	ドットケース-ユニフォーム）。
接続性を低減-1つの交換機→多くのキュー、不必要に「多くの交換機」ではありません。
マルチテナンシーの場合：クライアントごとのvhost/namespace、キーの接頭辞：'tenantX。支払い。psp……'。

キューとポリシー

ワークキュー：ビジネスハンドラによって消費されます。
再試行キュー：指数関数バックアップ用にTTL（遅延）とDLX（例えば、'5s→1m→5m→1h'）を使用します。
DLQ （Dead-Letter Queue）：レトラの消耗後の最後の「ダンプ」。
優先順位：緊急のタスク（結論>文字）。
遅延/クォーラム：遅延-大きなバックログでRAMを節約します。quorum-コンセンサスベースのHA。

ミニ政治家（概念）：

「仕事」だ。q'→'x-dead-letter-exchange=retry。'ex'
「再試行」1m。q'→'x-message-ttl=60000'、'x-dead-letter-exchange=work。'ex'
'dlq。q'→モニタリングと手動修復

配送保証と手続き

At-less-once-デフォルト：重複が可能→idempotenceが必須です。
At-once-最小限の遅延が、損失のリスク（「非クリティカル」信号の場合）。
正確に一度-ブローカーではめったに実用的ではありません。より困難で、より高価な達成。お金のために：少なくとも一度+ハードidempotence。

注文：

1つのキューと1つの消費者では、注文は保存されます。並列+再トレースを使用すると、順序が乱れる可能性があります。
注文要件を持つエンティティの場合は、ストリームをシリアル化するか（キーごとにシングルアクティブコンシューマー）、または「ログ」バスに転送します（ストリーミング）。

IdempotencyとTransactional Publis

メッセージ内のIdempotency-Key （ULID/UUID）、 TTL付きのデダップストレージ、またはキーごとにupsert。
Outboxパターン：ビジネス取引内の「outbox」テーブルにイベントを書き込むと、コネクタはブローカーに公開されます→「ダブルエントリ」/損失を除外します。
相関メタデータ：'message_id'、 'trace_id'、 'causation_id'、 'tenant_id'。

ブローカー経由のRPC（必要な場合）

リクエストは'reply_to'と'correlation_id'で公開され、レスポンスは指定されたキューにあります。
制限された（外部プロバイダ、同期チェック）、制御タイムアウトとチャットの傾向を使用します（そうでなければ-分散モノリスに劣化）。
ホットユーザパスの場合、非同期イベント+ステート投影が優先されます。

データ契約とスキーマ

フォーマット：Avro/Protobuf/JSONスキーマ。JSONの場合、バージョン管理と必須フィールドを修正します。
進化の政治：後方互換性のある変化；移行なしで変更を破ることは禁止されています。
PII-フィールドのトークン化/暗号化；目的および保存性。

エラー処理、リトレイ、DLQ

分類：一時的な（ネットワーク/5xx）リトレイ→；ファイル（検証/スキーム）→DLQ。
指数関数バックオフ+ジッタ、再試行限界、毒薬ラベル。
遅延配達：TTL/遅延交換経由。
原因を修正した後、DLQから「再取り込み作業」ツール。

観測可能性とSLO

生産者メトリクス：発行速度、エラー/確認。
キューのメトリクス：長さ、消費率、レトレイの割合、p99キューの時間。
消費者：遅延、スループット、処理時間、NACKシェア。
SLO： p99 E2Eイベント配信の遅延≤ X秒；99 ≥可用性。9%;DLQ率≤ Y％。
トレース：エンドツーエンドの'trace_id'/'span_id'、 'message_id'によるログ。
アラート：DLQ/lagsの成長、クォーラムドロップ、NACKサージ、再試行段階の付着。

セキュリティとアクセス

トランジット中のTLS/MTLS；永続キューが保存されているディスク上の暗号化。
RBAC/ACL： vhost/namespace/topicで権利を公開/消費します。
セグメンテーション：機密ドメイン（payment/CCM）-別々の取引所/クラスタ。
Vault/SOPSの秘密;publications/subscriptionsの監査ログ。
データのローカライズ：地域別のストレージと保持（EU、トルコ、LatAm）。

高可用性とDR

クォーラムキュー/レプリケーション、奇数ノード数、AZアンチアフィニティ。

クリティカルドメインのクロスリージョナルレプリケーション（フェデレーション/シャベル）

スイッチング規制（runbook）、定期的なDR演習（ゲームの日）。
コード（IaC）としてのトポロジーのバージョニング-繰り返し可能な預金と高速再同期。

パフォーマンスとチューニング

プロデューサー：パブリッシャーは、チャネルの再利用、非同期出版物を確認します。
キュー：タスクの平均期間のプリフェッチ；深いバックログのための怠惰。「ホット」キューをノードごとに分離します。
ネットワーク/OS： 10/25G、ファイル記述子、TCPチューニング。JVM/GC-ロードプロファイル用。
バースト負荷（試合、トーナメント、ピーク支払い）のテスト。

iGamingの典型的なルーティングパターン

1.決済イベント（トピック）：

交換： "支払い。トピックス'

キー：

「支払い」psp。ストライプ。成功しました'
「支払い」psp。。 failed'
'withdrawal。要求された。#`

コンシューマーキュー：

「レジャー」ライター。q '（bind：'支払い。#`)
'CRM。トリガーだ。q'（バインド：'支払い……succeeded'）
「リスク」レビュー。q '（bind：'引き出し。#`)

2.アンチフラウドスコアリング（ダイレクト+リトライ）：

「リスク」仕事だよ。q'： 'リスク。ダイレクト'（'routing_key=リスク。check'）

「リスク」再試行してください。1m。q '（TTL 60s→DLXは'risk。ダイレクト'）

「リスク」dlq。q'は致命的だ。

3.通知（fanout+priority）：

'notify。fanout'→'メール。q（プリオ）'、'sms。q'、'push。Q'

優先順位：マーケティングの郵送物の上の結論/限界。

4.監査とトレース（ヘッダー）：

ヘッダーバインディング'{「tenant「：「X「、「critical」：」 true」}'→別の監査キュー。

最小メッセージスキーム（JSON）の例)

json
{
"message_id": "01HX8H8Y6D6W0T1S2A3B4C5D6E",
"trace_id": "f4d2a1...e9",
"occurred_at": "2025-11-05T11:20:45. 321Z",
"tenant_id": "eu-1",
"schema_version": 3,
"event": "payments. psp. stripe. succeeded",
"payload": {
"payment_id": "pay_123",
"player_id": "p_987",
"amount": { "currency": "EUR", "value": 50. 00 },
"psp_tx": "tx_456",
"idempotency_key": "ulid_..."
}
}

他のループとの統合

ストリーミング/分析：重要なトピックは、レッチングと再処理のためのログバス（Kafka/Redpanda）で複製することができます。
Fichestor：イベント→オンライン機能（Redis）とオフラインパーティー（Parquet/OLAP）。
佐賀オーケストレーション：直接/トピック、イベント-パブ/サブコマンド；補償のステップ-別のメッセージとして。

実装チェックリスト

1.ドメイン交換器とルーティングキー標準を定義します。
2.クリティカルフローごとに作業/再試行/DLQを設計します。
3.必要に応じて、パブリッシャーの確認、'prefetch'、優先順位と遅延を有効にします。
4.idempotency-key、 outbox、 correlation IDを入力します。
5.データスキーマと進化規則を承認する。
6.TLS/RBAC、ドメイン/テナントによるセグメンテーションを構成します。
7.SLOとアラート（lag、 DLQ-rate、 p99）を設定します。
8.DR計画と自動化されたIaCトポロジーを準備します。
9.ロードとカオステストを実行します。
10.インシデントランブックを文書化し、DLQから再注入します。

アンチパターン

重要な規律のない1つの「巨大な」交換機。「バインディング」を指定する必要があります。
再試行/DLQの不在と時間的/致命的なエラーの混合。
ユーザーのホットパス上のブローカー上の同期RPC。
idempotencyとoutboxの欠如→2倍/お金の損失。
すべてのPIIストレージを明確にし、公開/消費します。

概要

よく設計されたMessage Brokerは、ルーティングが予測可能でフォールトトレランスがトポロジレベルで構築される堅牢なイベント動脈です。トピックエクスチェンジ、単一の鍵標準、各クリティカルストリームの作業/再試行/DLQ、 idempotencyとoutbox、厳格なSLOとオブザビリティを使用します。ストリーミングバスとステートプロジェクションと並行して、これはiGamingプラットフォームに負荷が増大するにつれて持続的な速度、透明性、複雑性の制御を提供します。