リアルタイムフィードイベント：アーキテクチャとセキュリティ

リアルタイムイベントフィードは、ゲーミフィケーション、不正防止、CRMトリガー、および支払いを備えた製品の「循環システム」です。それがピーク時に予測可能に動作するためには、重複した賞ではなく、データを漏らさないために、厳密なアーキテクチャが必要です。プロトコルとバスから署名、idempotency、予算のプライベーターとオブザビリティまでです。

1）目的と要件

信頼性：最低限の遅延を伴うイベントの配信（p95 ≤ 250 ms ingest、 p95 ≤ 1-2 s）。

配信：少なくとも一度の転送+idempotenceを介して正確に1回の論理。

順序：ウィンドウを並べ替えてキー（通常は'user_id'）で並べ替えます。

セキュリティ：MTLS、 HMAC/JWT、キー回転、再生/複製保護、PII最小化。

スケール：水平シャーディング、バックプレッシャー、レート制限、DLQ/リプレイ。

管理可能性：スキーマレジストリ、バージョン管理、ダウンタイムなしの移行。

コンプライアンス：監査（WORM）、 RG/KYCゲート、ジオポリシー、GDPR/匿名化。

2）リファレンスアーキテクチャ（レイヤーごと）

1.プロデューサー（ソース）：ゲームサーバー、ウォレット/決済、KYC/AML、クライアントSDK （web/iOS/Android）。

2.APIゲートウェイ（入力）：HTTP/gRPC受信、スキーマ検証、認証、HMAC/MTLS、時間正規化。

3.キュー/ストリーム：Kafka/Rabbit/Cloud Pub/Sub-バッファリング、'user_id'によるパーティショニング。

4.ストリームプロセッサ：ノーマライザー、濃縮、トピックのルーティング、異常/アンチボットフラグ、idempotent録音。

5.消費者：ルール/スコアリング、報酬オーケストレーター、CRM/CDPコネクタ、不正防止、分析シンク"と。

6.ストレージ：不変イベント、ストアフロント、idempotencyのインデックス、監査ログ。

7.観測可能性：メトリック、ログ、トレース、アラート；パニック→DLQ。

8.管理者平面：スキーマレジストリ、キー/シークレット、RBAC/ABAC、 phicheflags、リプレイサービス。

3）配達議定書： 何を使用するとき

HTTP/JSON （Server-to-Server Webhook）：シンプルで互換性があり、外部パートナーに適しています。HMAC+idempotencyを追加します。

gRPC/Protobuf：低遅延、厳格なスキーム、内部サービス用のbidiストリーム。

WebSocket/SSE：クライアントへのプッシュ、リーダーボードへのUIサブスクリプション、進行状況。

CDC/Kafka Connect：ソースがデータベース/ウォレットであり、ビジネスサービスではない場合。

推薦：外周-HTTP+HMAC+MTLS；内部-gRPC/Protobuf。

4）イベント・コンベンションモデル

json
{
「event_id"： 「e_01HF3Z8Z7Q8Q2K,」 「event_type"：「ベット」「schema_version"： 「1。3.0、」 「occurred_at"： 「2025-10-24T11:37:21Z,」 「ingested_at"： 「2025-10-24T11:37:21。183Z,」 「key」： {「user_id"： 「u_12345」}、 「ctx」：{
「session_id"： 「s_778,」「プラットフォーム」：「ios」、 「geo」： 「TR」、 「device_fp"： 「fp_4a1...」
}、「payload」：{
"game_id"： "slot_wolf," "bet"： 0。5「、勝つ」：1。25、 「currency」： 「EUR」、 「provider」： 「GameCo」
}、「sig」：{
「algo」： 「HMAC-SHA256,」 「kid」： 「k_2025_10,」 ts'： 1730061441、 「mac」： 「c7b7b3…… f1」
}
}

ルール：

2回は'concept_at' （source）と'ingested_at' （gateway）です。時計が300秒±ドリフトできるようにします。
ルーティングキーは、順序を決定するものです（通常は'user_id'）。
最小化原理の'ctx'/'payload'でのみPII；敏感な属性、トークン化のために。

5）配達、順序およびidempotence

1回以上のトランスポート→重複と並べ替えが可能です。

正確に一度のロジック：'（）'および/または'（、）'に一意のインデックスを持つidemotenceテーブルを保持ます。繰り返す-no-op。

SQLスケッチ：

SQL
テーブルの作成event_log（
event_id TEXT主キー、user_id TEXT、 event_type TEXT、 occurred_at TIMESTAMPTZ、ペイロードJSONB
);

--二重保護された挿入
event_logに挿入（event_id、 user_id、 event_type、 occurred_at、ペイロード）
値（:event_id,:user_id,:event_type,:occurred_at,:payload）
競合（event_id）何もしない；

Order： 'user_id'によるストリームの分割+プロセッサ内のウィンドウ60-120 secの並べ替え。その後、来るイベントは、是正関数の「リプレイ」になります。

6）背圧およびピーク管理

Token-Bucketレート制限入力（IPごと、パートナーごと、キーごと）。

サーキットブレーカ：内部消費者から5xxで、劣化→（オプションのイベントのドロップアウト、キューはリトレイ間隔を増加）。

DLQ：永久に誤ったメッセージ（ビットマップ、署名無効、署名TTL超過）。

リプレイサービス：'event_id'/時間範囲による選択的DLQリプレイ。

7）スキームと進化： prodを「壊さない」方法

スキーマレジストリ：JSON スキーマ/Protobuf；互換性ポリシー：生産者のための後方、消費者のための前方。

バージョン管理：'schema_version'、メジャー-ficheflagとdouble-write （dual-write）のみ。

契約：カナリア期間とグリーンメトリック後のスキームのプロモーション。

YAMLの検証ルールの例：

yaml互換性：
enforce： trueモード：後方blocked_fields：
-ペイロードだ。SSN
-ペイロードだ。   ：
-event_id
-event_type
-occurred_at

8）脅威モデルと保護

脅威：ボディスプーフィング、リプレイ、PIIリーク、キー侵害、スキーマ中毒、DoS、 MITM、署名ストリッピング。

保護：

周囲のMTLS：短期クライアント証明書、CRL/OCSP。
HMAC body signature+'X-Timestamp'およびTTL （± 300 s）。
JWT（クライアントcredentials/OAuth2）-認可およびスコープ制限のため。
キーの回転（KMS）：ヘッダーの'子供'；回転計画30-90日；マイグレーションウィンドウをダブルチェックします。
Nonce/idempotency：サイドリクエスト（支払い、ボーナス）の'X-Request-Id'；しばらくTTLを維持してください。
コンテンツタイプのピン留め、最大ボディサイズ、重要な統合のためのallow-list IP/ASN。
すべてのraw-payload+ヘッダー（変更できないストレージ）のWORM監査。

HMAC（擬似コード）テスト例：

python body=request。raw_body ts=int（リクエスト。ヘッダ［」X-Timestamp」］）
assert ABS （now（）-ts）<<=300#アルファベット-リプレイkid=request。ヘッダ［」X-Key-Id」］
シークレット=kms。fetch（子供）
mac=hmac_sha256（シークレット、ボディ）
assert hmac_eq （mac、 request。ヘッダ［」X-Signature」］）

9）プライバシー、PIIおよびRG/KYC

最小化：インラインの代わりにトークンリンク（5〜15分間）でPIIを転送します。rawログでの編集/匿名化は禁止されています-別のPIIページを使用してください。

アクセス：管轄および役割の属性によるABAC；すべての読み取り-監査ログに。

GDPR：イベントの事実を破ることなくPIIを消去するために、キーマッピングを介して削除する権利を行使します。

RG/KYC：貴重な報酬が必要なイベントは、有効なKYCレベルとRGフラグ「OK」のみでスキップします。

10）観察可能性およびSLO

SLO（例）：

p95 ≤ 250ミリ秒を入力します。エンドツーエンドのp95 ≤ 2インチ；≤ 0の失敗。1％/日。
エラー署名（HMAC/JWT） ≤ 0。02％の総流量。
DLQ塗りつぶしレート≤ 0です。1%;idempotency ≤ 0の後の「duplicates」。005%.

ダッシュボード：

ソース別のRPS、 p50/p95レイテンシ、4xx/5xx、エラー署名、タイムスキュー。
パーティーによる遅延、処理/秒、DLQの埋め、再試行、リプレイボリューム。
スキーム：バージョン別のメッセージの共有、互換性違反。
安全：rpsスロットルレート、サーキットブレーカ、IP/ASN異常。

アラート（例）：

フローのSRM （1つのソースからのトラフィックの急激な歪み）。
レイテンシp95>ターゲット5 min+、DLQ成長>X/min。
エラー署名>Y ppm、 'X-Request-Id'リプレイスパイク。
源のドリフト時間>120 s。

11）複数の地域および欠陥の許容

アクティブ-アクティブ領域、グローバルルーティング（GeoDNS/Anycast）、 sticky-key by 'user_id'→region。

重要なイベント（金融、KYC）のクロスリージョナルレプリケーションのトピック。

ブラスト半径：テナント/ブランド、個々の予算とキーによる分離。

DR計画：RPO ≤ 5分、RTO ≤ 30分；定期的なリハーサル。

12）保持およびリプレイポリシー

生のイベント：7-30日（コスト別）、集計/ショーケース-長い。

リプレイは、署名されたランブック（who、 what、 why、 time range）によってのみ許可されます。

リプレイは、分析透過性のための'replayed=true'フラグを使用して、常に新しいストリームバージョンに移動します。

13）構成例

入力（NGINXスタイル）の制限：

nginx limit_req_zone$binary_remote_addr zone=req_limit： 10m rate=300r/s；
limit_req zone=req_limit burst=600 nodelay；

client_max_body_size 512K；
proxy_read_timeout 5s；

カフカ（例）：

プロパティnum。 partitions=64 min。 insync。replicas=2 acks=すべての保持。ms=604800000#7日の圧縮。type=zstd

キー（KMS）のポリシー：

yaml rotation_days： 45 grace_period_days： 7 allow_algos： ［「HMAC-SHA256」］
key_scopes：
-トピック：「wallet_events」
プロデューサー：［「wallet-svc」］
消費者：［「ledger-svc「、「risk-svc」］

14）リアルタイムフィード起動チェックリスト

周囲のMTLS、 HMAC/JWT、キー回転（'kid'）。
ロジック上のIdempotence（一意のキー、upsert/ON CONFLICT）。
'user_id'によるパーティショニング、ウィンドウの並べ替え、リプレイサービス。
スキーマレジストリ+互換性ポリシー；主要な更新のためのデュアルライト。
レート制限、サーキットブレーカ、DLQ+マニュアルレビュー。
Observability： SLO、 signature/latency/DLQ/lagによるアラート。
PII/匿名化ポリシー、ABAC、 WORM監査。
DR/multi-region、 feiloverリハーサル。
Runbooks：インシデント、リプレイ、スキーマ/キーのロールバック。

15）ミニケース（合成）

コンテキスト：トーナメントのピーク、120からRPSの入力、64ゲーム、2アクティブ-アクティブ領域。

合計4週間： インジェストp95 210 ms、 e2e p95 1。6 s；DLQ 0。05%;エラー署名0。009%;idempotency 0の後に重複します。003%.

インシデント：パートナーのクロックドリフト（− 9分）→アンチリプレイサージ。サーキットブレーカは、ストリームを「バッファ」エンドポイントに転送しました。NTPのあざの後-窓はすべての消費者に12分を再生します。損失や二重支払いはありません。

16）概要

信頼できるリアルタイムフィードは「単なるWebhook」ではありません。"これは明確な契約を持つレイヤードシステムです：少なくとも一度のトランスポート+論理的正確に一度、スキームとバージョンの登録、MTLS/HMAC/JWTとキー回転、バックプレッシャー/DLQ/リプレイ、 PII最小化と厳格な監査。これらの慣行に従うことによって、あなたは自信を持ってゲーミフィケーション、詐欺対策、CRMと支払いを構築することができます上のイベントの高速、安全かつ予測可能なストリームを取得します。