トレントギア

1日あたり数百万件のトランザクションのフェイルセーフ処理を構築する方法

完全な記事

💡 fintech/gamingおよび関連産業のプロダクトそしてプラットフォームチームのための技術的な材料。再生する呼び出しではありません。「取引」とは、金融・会計取引（債権、クレジット、譲渡、決済、リターン）を意味します。

1）トランザクションのフェイルセーフとは何ですか？

フェイルセーフとは、失敗した状況が、お金とデータを失うことなく安全な停止または補償された状態につながる場合です。目的：

「ダブルデビット/クレジット」=0。
ロストトランザクション/イベント=0。
遅延/配信、明確な劣化モード、DRRによる予測可能なSLO。

基礎-通貨不変量（1つの場所で真のバランス）、idempotence、イベントの合意された配信。

2）建築の原則（短い）

1.真実の単一のソース：貸借対照表と会計-Ledger/Walletで。周りのサービスは、お金ではなく、プロセスの状態を保持します。

2.どこでもIdempotency：すべての「書き込み」操作は'Idempotency-Key'を取ります；repeatは同じ結果を返します。

3.配達保証付きイベント：outbox/CDC、キュー、DLQ、デッドアップ。

4.サガと補償、ない「手動編集」。

5.背圧と優先順位：システムは遅くなりますが、崩壊することはありません。

6.デフォルトのオブザビリティ：構造化ログ、トレース、メトリック。

7.マルチリージョンとDR：資産-資産/資産-責任、定期的な演習。

3）参照トポロジー


Edge/API GW──コマンドAPI──App Service （Sagas）
│           │
（Outbox TX）

RateLimit Outbox Table──パブリッシャー──カフカ/パルサー──消費者
│                      │
WAF └─DLQ/Replay
│
└─Ledger/Wallet （ACID、 idempotent debit/credit）
│
└─CDC/Changefeed──DWH/BI/Recon

重要な場所：Outbox（チームの原子記録とイベントの「ドラフト」）、Publisher（正確に1つの配信）、Consumers （idempotent、 dedup key付き）、DLQ/Replay（制御された繰り返し）。

4）通貨の不変性および一貫性

バランスによって真-レジャー（ACID、シリアライズ可能なトランザクション、またはアカウントによる厳格な注文）。

マネーコマンド：'debit'、 'credit'、 'hold'、 'commit'、 'rollback'はidempotentです。

組み合わせたプロセスはサガのように構築されます：

'authorize→settle→credit'、 'request→submit→settled/failed'、 'refund/void'。
Ledgerをバイパスする直接の貸借対照表の編集はありません。

5） Idempotence： 主設計

キーはビジネス取引を一意に識別する必要があります：

'bet_id+amount+currency'、 'payment_intent+capture_id'、 'payout_id'、 'chain_txid'。
結果をキー（レスポンスキャッシュ）で保存します。同じキー→同じボディ/ステータスで繰り返します。
mismatchを監視する-同じキーと異なる量→'IDEMPOTENCY_MISMATCH'。

6）キュー、順序およびデッドアップ

正確に一度の効果は、トランスポートではなく、idempotent consumer+dedup storage （LRU/Redis/DB c TTL）によって達成されます。

キーオーダーを保持します（パーティションキー='account_id/round_id/player_id'）。

「異機種混在」キーの場合-エンティティごとのステートマシン。

DLQは必須です：Nの試みの後-人間が読める原因を持つ孤立したトピックに。

7） Outbox/CDC： イベントが「迷子にならない」理由"

1つの取引の枠組みの中で、サービスデータベースにビジネス変更とアウトボックスエントリの両方を記録します。

別のパブリッシャーがアウトボックスを読み取り、確認バスにパブリッシュします。

または、データベースレベル（Debezium/replication log）のCDC （Change Data Capture）を使用します。

トランザクションを過ぎた「イベントログ」は損失の原因にはなりません。

8）背圧および優先順位

トークンバケットと入力クォータ（テナント/ブランド/地域ごと）。

優先キュー：プロモ/テレメトリーの上のマネーパス。

overloaded：モード'no new sessions/requests'、セカンダリ機能のフリーズ、カーネルの保存。

自動劣化：バックグラウンドタスクの頻度を削減し、クリティカルワーカーを動的に拡張します。

9）複数地域の持続可能性

APIおよびキュー、ローカルLedger（または地域/通貨のシャーディングを含むグローバル）の資産。

データレジデンシー：明示的なルールがなければ、Money/PII/logsは交差しません。

イベントのレプリケーションは地域間-非同期で'region'とマークされています。

RPO/RTO：目標RPO ≤ 5分、RTO ≤ 30分；定期的にチェックしてください。

10） SLO/SLIおよびダッシュボード

ランドマーク（例）：

p95 'authorize/debit/credit' <150-300 ms（内部パス）。
p95エンドツーエンド「bus komanda→sobytiye」 <1-2 s。
Webhook/外部イベントの配信p99 <5分。
紛失/複製されたトランザクション=0（契約チェック）。

メトリクス：latency p50/p95/p99、 error-rate （4xx/5xx/business）、 consumer/queue lag、 retry storms、 settle lag、 webhook lag、 DLQ size、 'IDEMPOTENCY Y Y_MISATCH CH'周波数。

11）観察可能性および監査

構造化されたJSONは'trace_id'、 'idempotency_key'、ビジネスID、エラーコードでログを記録します。

OpenTelemetry： HTTP/gRPC/DB/バストレーシング、サガのスパン。

WORM監査：変更できない重要な変更ログ（制限、キー、プロモーション/ジャックポットコンフィギュレーション）。

PII/シークレットマスキング、地域のバケツ、ログアクセスのためのRBAC/ABAC。

12）信頼性試験

契約テスト：繰り返し/重複、順序外れ、idempotency、 dedup。

ロード：ピークプロファイル（x10）、キューとDBの安定性。

カオスケース： 元帳/ウォレットドロップ、キュー/リージョンのダンプ、CDCの遅延、「嵐」の再試行"

ゲームの日：MTTRを測定した通常のDRドリルとインシデント。

13）貯蔵およびデータ

お金のためのOLTP：トランザクションデータベース（RPO≈0）、厳格なインデックス、重要なエンティティのシリアライズ可能なレベル。

キャッシュ（Redis）-「真実」のためではなく、加速のためにのみ。"TTL+ジッタ、キャッシュスタンピード保護。

OLAP/DWH-レポート/分析用。CDC/バスからの流れ、OLTPの負荷無し。

データスキーマはバージョン管理されています。ダウンタイムなしの移行（拡張/契約）。

14）リトレースのオーケストレーション

指数関数バックオフ+ジッタ、RPCの締め切り/タイムアウト。

各レイヤー（クライアント→サービス→コンシューマー）でのIdempotentリピート。

レトライクォータは、「嵐」（遮断器、ヘッジリクエストが適切な場合）から保護します。

DLQから「安全」ウィンドウにのみリプレイし、制限速度を設定します。

15）輸送の安全

どこでもmTLS S2S、短命トークン（OAuth2 CC）、 Webhook用のBody Signature （HMAC/EdDSA）。

Vault/HSMの秘密、回転、ブランド/地域ごとのキー。

政治家は少なくとも特権、手動操作に「4つの目」。

16）サンプル契約（フラグメント）

Idempotent Debitコマンド


POST/v1/ウォレット/デビット
ヘッダー：X-Idempotency-Key： debit_pi_001、 X-Trace-Id： tr_a1b2
{
"account_id":"acc_42,""量"：{"minor_units'： 5000、" currency"："EUR"}、"reason"："payout"、"reference_id":"po_001"
}
→200{「ステータス「：「コミット」、「entry_id":"e_77」}
（リピート→同一回答）

アウトボックスからのイベント

json
{
「event_id":"uuid,」 「event_type":"wallet」。デビットだ。コミット、"" "" " "、通貨"："EUR"、" "" "。3.0"
}

17）チェックリスト

プラットフォーム/オペレーター

バランスにTrue-1つの元帳；回避策はありません。
'Idempotency-Key'のすべての書き込み操作；キー応答が保存されます。
すべてのドメインレコード、DLQ、マネージドリプレイへのOutbox/CDC。
優先キュー、背圧、劣化モード。
パーティションキーはビジネスキーによって選択されます。消費者は馬鹿げています。
SLOダッシュボード、OpenTelemetry、 WORM監査。
規則的なDR/xaocの練習、契約/負荷テスト。
データ常駐、暗号化、Vault/HSM、キー回転。

プロバイダ/インテグレーション

Trace-Id/Idempotency-Keyを送信し、再配達の準備ができました。
Webhookは署名され、重複除外されます。
スキーム/契約のバージョンが観察される（semver、 deprecation）。

18）赤旗（アンチパターン）

レジャーのコマンドなしでWebhookでバランスが変わります。

idempotency→double write-off/creditsの欠如。

outbox/CDCをバイパスするイベントの発行。

バックプレッシャーなしのモノリス：ピーク時のトラフィックはすべてをダウンさせます。

OLTPとレポートのミキシング：BIが戦闘データベースにヒットします。

DLQ/リプレイがない。エラーの「静かな」摂取。

地域のPII/お金の分離無し；複数のブランドの共有キー。

データベース内の残高/ステータスの手動編集。

19）ボトムライン

1日あたり数百万件のトランザクションのフェイルセーフ処理は、不変量と規律に関するものです。真実の単一のソース、idempotentコマンド、サガとアウトボックス/CDC、キューの順序とデッドアップ、オブザビリティ、管理された劣化です。アクセス義務、DRプラクティス、定期的な演習を追加し、お金が素早くかつ一度だけ移動するシステムを取得し、イベントが失われることはなく、トラフィックの増加と混乱は驚くべきことではなく、管理可能なリスクになります。