フラッシュコンサート販売向けチケット予約システムの設計

前提条件：購入者はチェックアウト前に認証されており、決済プロバイダーは冪等性キーと、承認後に実行されるキャプチャをサポートしており、8分間の保留は購入を完了するための期限であり、最後の瞬間に開始された支払いが成功することを保証するものではありません。あいまいな地域障害が発生した場合、可用性よりも安全性が優先されます。

アーキテクチャ：CDNとボット対策を、仮想待合室、APIゲートウェイ、ステートレスな座席マップ、予約、注文、決済サービスの前段に配置します。サービスはプライマリリージョン内の複数のアベイラビリティゾーンで実行し、セカンドリーリージョンにはウォームスタンバイを配置します。セール対応サービスは自動スケーリングします。座席の状態、保留、注文、ユーザーごとの制限の権威として、1つのトランザクションデータベースを使用します。コミットされた状態はセカンドリーリージョンに同期的にレプリケートします。データベースのアウトボックストランザクションイベントをメッセージバスに発行し、通知とキャッシュの更新に使用します。座席マップはキャッシュから提供し、更新はクライアントにプッシュします。表示される空き状況は参考情報であり、保証ではありません。クリティカルな書き込みパスは、キャッシュやメッセージバスから独立させます。

保留と購入：各イベント・座席ペアに1つのデータベース行を割り当てます。保留リクエストは、購入者のイベントごとの制限レコードと要求された座席行を一貫した順序でロックし、購入者が最大6席までしか保留しないことを確認し、利用可能な座席または保留が期限切れになった座席をアトミックに確保します。保留所有者、トークン、有効期限はデータベース時間を使用して格納します。クライアントが明示的に少ない座席数を受け入れない限り、部分的な成功なしに競合を返します。キャッシュエントリもタイマーも所有権を決定しません。すべての競合する保留と購入は、トランザクション内で権威ある行をチェックします。ワーカーは、迅速なマップ更新のために保留を期限切れにしますが、読み取りと書き込みも期限切れの保留を利用可能とみなすため、ワーカーの失敗によって座席が取り残されることはありません。

チェックアウト時に、保留と冪等性キーに関連付けられた耐久性のある注文試行を作成します。決済承認が確実に成功した後、すべての座席がまだその保留に属しており、期限切れになっていない場合にのみ、座席をSOLDに、注文をCONFIRMEDにアトミックに変更します。確認とそのアウトボックストランザクションイベントを一緒にコミットします。確認後に決済をキャプチャします。失敗したキャプチャはリトライし、運用上調整します。確認が期限切れとの競争に負けた場合は、承認を無効にするか返金します。販売された座席が保留期限切れによって再び利用可能になることはありません。クライアントのリトライは同じ試行キーを使用し、別の購入を作成するのではなく、既存の結果を取得します。

オープニングセールトラフィックと公平性：ユーザーは、ウェブサーバーの数ではなく、測定されたデータベースと決済の容量によって制限されたレートで待合室から入場させます。発表されたオープニング前に待機しているユーザーの間で位置をランダム化し、その後、後から到着したユーザーを到着順に入場させます。署名された、有効期限の短い入場トークンを発行します。アカウントごとの購入制限、ボットチャレンジ、レート制限を、繰り返しリフレッシュしても位置が改善されないように強制します。キューの位置推定を表示し、非本質的なトラフィックを削減します。静的な座席マップジオメトリをCDNにキャッシュし、空き状況の更新を統合します。同時保留とチェックアウトを制限します。ロック競合、決済バックログ、またはエラー率が上昇すると、入場が遅くなります。閲覧のために入場したユーザーは、保留トランザクションがコミットされるまで座席の優先権を得られません。

決済の不確実性：プロバイダーの呼び出しをまたいでデータベースロックを保持しないでください。リトライやウェブフックにはプロバイダーの冪等性キーを使用し、タイムアウトした、または不明確な承認を調整するための証拠とします。HTTPタイムアウトは却下ではありません。別の試行を行う前にプロバイダーに問い合わせ、不明確な試行は保留中のままにします。確定的な承認と成功した座席トランザクションなしに注文を確認しないでください。8分間の期限が先に経過した場合、座席は回収される可能性があります。その後に行われた承認は、確認済み注文に変換されるのではなく、無効または返金されます。解決されていない試行についてアラートを出し、プロバイダーの決済記録と照合します。二重請求や販売のリスクを避けるために、照合が安全でない場合は新規チェックアウトを無効にします。

信頼性と目標：マルチゾーンインスタンス、ロードバランサー、データベースフェイルオーバーは、通常のノードまたはゾーンの障害を処理します。ステートレスサービスは再起動できます。キャッシュの障害は、レート制限された権威ある読み取りにフォールバックします。バスの障害はマップと通知の遅延を引き起こしますが、購入には影響しません。データベーストランザクション、耐久性のあるログ、確認応答前のクロスリージョン同期レプリケーション、バックアップ、復元テスト、アウトボックプレイは、確認済み注文を保護します。スタンバイをウォーム状態に保ち、セール負荷下でフェイルオーバーをテストします。昇格には、古いライターをフェンスし、レプリケートされた進捗を確認する必要があります。2つのリージョンだけでは、ネットワークパーティション中の即時書き込みとゼロ失効確認の両方を安全に保証することはできません。フェンスまたはレプリケーションが不確実な場合は、購入を一時停止します。定義された月次ウィンドウで99.95%の購入フロー可用性を測定します。プロバイダー障害や入場障害も除外せず、それに対して容量とフェイルオーバー時間を予算計上します。十分に長いリージョンパーティションは、過剰販売を許可するのではなく、ターゲットを侵害する可能性があります。

トレードオフ：Redisロックではなくトランザクションシートデータベースを使用します。書き込みコストが高くなりますが、監査可能でアトミックな所有権と注文が得られます。アクティブ・アクティブの座席書き込みではなく、フェンスされたフェイルオーバーを持つ単一のライターを使用します。地理的な書き込み可用性は低下しますが、競合する所有者はいません。すべてのビューアに対してデータベースを読み取るのではなく、キャッシュされた、わずかに古いマップを使用します。選択時に競合が発生する可能性がありますが、500,000人のユーザーの到着が権威を圧倒することはありません。無制限の自動スケーリングではなく、制限された入場を使用します。一部のユーザーは待機しますが、入場したチェックアウトは使用可能であり、インフラストラクチャはすべての急増に対応するためにプロビジョニングする必要はありません。決済が不確実でも期限切れの保留を解除します。無期限に延長するのではなく、在庫は時間通りに戻りますが、時折無効または返金が発生する可能性があります。

セールダッシュボードとアラート：キューの深さ、待機時間分布と入場率、APIの可用性とレイテンシ、保留の成功、競合、期限切れラグ、ユーザーごとの制限違反とデータベースロック待機、チェックアウトコンバージョンと注文確認レイテンシ、決済タイムアウト、保留中の試行の経過時間、承認から確認への不一致、返金とキャプチャの失敗を追跡します。重複座席の不変条件違反または確認済み注文の喪失が発生した場合は即座にアラートを発し、レプリケーションラグ、フェンスの失敗、データベース容量の低下、5xxエラー率の上昇、過剰な決済の不確実性、期限切れバックログについてはページングします。キャッシュの鮮度とアウトボックラグを、権威ある購入の健全性とは別に追跡します。

1. ハイレベルアーキテクチャとデータストア：アーキテクチャは、アクティブ-パッシブマルチリージョンセットアップ（プライマリリージョンAがすべてのトランザクション書き込みを処理し、リージョンBがディザスタリカバリとリージョン別読み取りトラフィックのホットスタンバイとして機能）を活用しています。エッジ/仮想待機室：CDNレイヤー（例：Cloudflare）がすべてのトラフィックの前面に配置され、エッジ仮想待機室と統合されて、最初の50万ユーザーのスパイクを吸収します。APIゲートウェイ：認証されたトラフィックをルーティングし、レート制限を実行し、署名付きキュー入場トークンを検証します。座席利用可能性サービス（読み取りパス）：インメモリキャッシュ（Redis）から会場の座席ステータスを読み取り、CDNキャッシュ可能な座席マップのスナップショット（SSEまたはショートポーリング経由で1〜2秒ごとに更新）を提供します。保留および予約エンジン（書き込みパス）：Go/Javaマイクロサービスが、リレーショナルデータベースをバックエンドとするインメモリトランザクションキャッシュレイヤー（Redis Cluster）に対して座席予約コマンドを実行します。注文および支払いサービス：注文ライフサイクルをオーケストレーションし、支払いプロバイダーと支払いインテントを作成し、Webhookをリッスンし、ステータスの照合を処理します。データストア：（a）Redis Cluster：イベントIDでシャーディングされ、座席ステータスビットマップと保留リース（TTL：8分）を保持して、マイクロ秒単位の座席ロックを行います。（b）リレーショナルデータベース（Amazon Aurora PostgreSQL Multi-AZ）：座席、保留、注文、チケット、および財務元帳の権威ある記録システムであり、ACIDトランザクションを使用してゼロオーバーセリングを保証します。（c）Kafka / SQS：注文完了イベント、通知、チケットPDF生成、支払い照合のための非同期メッセージバス。2. 座席保留、同時実行性、および有効期限：ゼロオーバーセリングは、2フェーズ予約モデルを通じて保証されます。フェーズ1（インメモリ保留）では、座席選択リクエスト（最大6席）が保留エンジンにヒットします。Redis Luaスクリプトは、要求された座席のビットマスクまたはハッシュステータスをアトミックに検査します。すべての座席が「利用可能」な場合、それらを「保留中」とマークし、{user_id、hold_id、timestamp、seat_ids}を含む保留レコードを書き込み、厳密な480秒のTTLを設定します。いずれかの座席がすでに「保留中」または「販売済み」の場合、Luaスクリプトは部分的な割り当てなしでクリーンに中止されます。フェーズ2（権威あるデータベース保留）では、単一のトランザクション内でAuroraに冪等なDBレコードが作成されます：INSERT INTO holds (id, user_id, event_id, seat_ids, expires_at) VALUES (...)。座席ステータスを「保留中」に更新します。有効期限処理：ユーザーが8分以内に購入を完了しない場合、Redis保留はキー有効期限イベント（Auroraをスキャンする耐久性のあるバックグラウンドリーパーによってサポートされるRedis Keyspace Notifications、expires_at < NOW() AND status = HELD）を介して期限切れになります。リーパーは、Auroraの座席ステータスを「利用可能」にアトミックにフリップし、Redisビットマスクを復元して、アクティブな買い物客に座席を即座に解放します。購入の最終化：支払い確認時に、AuroraのACIDトランザクションが座席を「販売済み」に更新し、注文を「支払い済み」とマークし、不変のチケットレコードを生成し、Redis座席ステータスを「販売済み」に更新します。3. トラフィックの急増、入場制御、および公平性：2分以内に50万人の同時ユーザーを処理するには、下流サービスが容量内で厳密に動作するように、積極的な入場制御が必要です。エッジ待機室：販売開始前および販売中に到着したユーザーは、軽量のエッジ待機室にリダイレクトされます。T-0前に到着したユーザーは、プレセールプールに配置されます。T-0で、最初のバースト内の到着順序はランダム化され、ミリ秒単位のボットの利点が排除され、その後、厳密なFIFOキューイングが適用されます。レート制限された入場：システムは、会場のサイズと処理能力に基づいて入場スループットを計算します（例：10秒ごとに1,000ユーザーを入場させます）。入場したユーザーは、インタラクティブな座席マップとチェックアウトパイプラインへの入場を許可する、{user_id、queue_slot、expires_at}を含む暗号化されたHMACトークンを受け取ります。座席マップの最適化：50万人のユーザーのために6万席のマップを動的に生成すると、データベースがクラッシュします。代わりに、座席マップの状態は、1秒のTTLでCDNエッジにキャッシュされた圧縮バイナリベクトルまたはデルタJSONチャンクとしてレンダリングされます。ユーザーは静的な会場ジオメトリを一度取得し、次に1秒のキャッシュバスター付きの座席ステータスデルタを取得して、バックエンドの読み取り負荷を500 RPS未満に保ちます。4. 支払い統合と障害処理：支払いは非同期ステートマシンを通じてオーケストレーションされます。ステップ1（チェックアウト開始）：ユーザーが支払いフローに入力し、システムは「保留中」ステータスの内部注文を作成し、それを保留IDにリンクします。冪等性キー（order_id + attempt_count）が生成されます。ステップ2（外部プロバイダーとの連携）：フロントエンドは、プロバイダーのクライアントサイドSDK（トークン化されたカード）を使用して支払い詳細を収集し、請求インテントを送信します。p99レイテンシは3秒であるため、API呼び出しは、注文ステータスのクライアントサイドポーリングで非同期に実行され、同期HTTPスレッドブロッキングは行われません。タイムアウトと不明瞭な結果：呼び出しがタイムアウトするか、あいまいなネットワークエラーが返された場合、注文サービスは注文を直ちに失敗させません。代わりに、注文を「支払い検証中」に配置し、フォールバックワーカーを開始して、指数バックオフ（例：2秒、5秒、10秒）でプロバイダーのGET /charges/{idempotency_key}エンドポイントをポーリングします。保留延長バッファー：注文が8分間の保留期限切れの60秒以内に「支払い検証中」に入った場合、請求が決済されている間に座席が解放されるのを防ぐために、システムはRedis保留に自動的に2分間の安全延長を付与します。Webhookの取り込み：支払いゲートウェイからのWebhookは、HMAC署名によって検証され、処理の前に直接耐久性のあるキューに書き込まれ、冪等なステータス更新が保証されます。照合ワーカー：毎時の照合ジョブは、支払いゲートウェイの決済レポートとデータベースレコードを比較して、未処理の請求または未処理のチケットを検出します。5. 信頼性、フェイルオーバー、およびデータの耐久性：可用性（99.95％）とゼロデータロス：（a）データベース層：Aurora PostgreSQLは、自動同期ストレージレプリケーションとリードレプリカを備えた3つのアベイラビリティゾーンにまたがって実行されます。プライマリライターが失敗した場合、30秒未満でレプリカが昇格される自動フェイルオーバーが行われます。（b）インメモリ層：Redisは、AZをまたぐクラスター化されたマスターレプリカトポロジーで動作します。まれにRedisが回復不能なクラッシュが発生した場合、シートステータスは、Auroraシートテーブルに対する高速インデックススキャンを実行するウォームアップジョブによって15秒以内に再構築されます。（c）リージョンディザスタリカバリ：クロスリージョンAuroraストレージレプリケーションは、1秒未満のRPOを維持します。リージョンBはコールド/ウォームスタンバイで構成されています。リージョンAでクラウドプロバイダーの大規模な障害が発生した場合、DNSフェイルオーバーがトラフィックをリージョンBにリダイレクトし、そこでサービスは自動スケールして運用を再開します。（d）冪等性：すべてのAPI（保留、支払い、解放）は、再試行中の重複した副作用を防ぐために、データベースレベルの一意制約とRedis冪等性トークンを強制します。6. 主要なアーキテクチャのトレードオフ：（1）インメモリRedis Luaロッキング対純粋なデータベース行レベルロッキング（SELECT FOR UPDATE）。却下：PostgreSQLでの直接行レベルロックは、50万件の同時リクエストに対して大規模なロック競合、トランザクションキューイング、および接続枯渇を引き起こします。選択：初期保留調停のためのRedis Luaアトミックスクリプト。Postgresへの非同期/逐次永続化。トレードオフ：マイクロ秒単位のレイテンシとデータベースの飽和ゼロのために、わずかに複雑な二重レイヤー状態同期。（2）エッジでの仮想キュー対バックエンドサービスの大量自動スケーリング。却下：6万席しかないイベントの50万件の生RPSを処理するためにKubernetesポッドとデータベースを動的にスケーリングすることは、コストがかかりすぎ、Auroraの書き込みスループットによって制限されます。選択：制御された入場レートによるエッジキューイング。トレードオフ：ユーザーはキューで待機しますが、システムの安定性、運用コスト、およびユーザーエクスペリエンスは予測可能で堅牢なままです。（3）CDNキャッシュデルタポーリング対ライブシートマップ用のフルデュプレックスWebSockets。却下：50万件の永続的な双方向WebSocket接続を維持することは、アプリケーションサーバーに深刻なステートフル接続オーバーヘッドを課します。選択：短時間キャッシュ（1秒）CDNデルタポーリング。トレードオフ：ユーザーの座席状態の視覚化における1秒のレイテンシ。これは、クリック時のトランザクションLua保留検証を考慮すると、完全に許容範囲です。7. 主要な運用メトリクスとアラート：メトリクス：（a）エッジキューの長さと流入率。（b）保留作成率と放棄率。（c）Redisメモリ使用率、CPU、およびLuaスクリプト実行レイテンシ（p95、p99）。（d）データベースのアクティブ接続数、書き込みレイテンシ、およびレプリケーションラグ。（e）支払いゲートウェイのレイテンシ（p50、p99）、エラー率（5xx/タイムアウト）、およびWebhook取り込み遅延。（f）不変違反カウンター：COUNT(DISTINCT order_id) WHERE seat_id = X AND status = 'SOLD' > 1（厳密に0）。クリティカルアラート：（1）不変違反：過剰販売された座席の検出（P0、即時ページ）。（2）支払いタイムアウトスパイク：1分間の支払いタイムアウト率が5％を超える（P1）。（3）Redisメモリ/ CPU：CPUが75％を超えるか、エビクションカウントが0を超える（P1）。（4）期限切れ保留リーパーラグ：リーパーキュー遅延が30秒を超える（P2）。