スケーラブルなコンサートチケット予約システム — 設計計画

1. 前提条件

• 単一のクラウドリージョン（例：AWS us-east-1）、3つのAZを使用。マネージドサービスを優先。
• カタログ（イベント、会場、座席マップ）は読み取り負荷が高く、変更はまれ。
• 予約はホットパスであり、決済は非同期コールバックを介したオフホットパス。
• 「決して売り切らない」は厳格な不変条件であり、二重販売よりも一時的な利用不可を優先する。
• 外部決済プロバイダー（例：Stripe/Adyen）がPCIスコープを処理し、トークンのみを保存する。
• 平均イベントサイズ30,000席。ピーク時のバーストは数分から約1時間持続する。

2. ハイレベルアーキテクチャ

クライアント（Web/モバイル）→ CDN（CloudFront）→ API Gateway / L7ロードバランサー → エッジ認証（JWT）→ 3つのAZにまたがるKubernetes（EKS）上のステートレスマイクロサービス。

コアサービス：

• Identity Service: サインアップ、ログイン、JWT発行、MFA。
• Catalog Service: イベント、会場、座席マップのメタデータ。読み取り最適化。
• Inventory/Seat Service: 権威ある座席状態、ホールド、予約。一貫性のアンカー。
• Reservation Service: ホールド → チェックアウト → 決済意図をオーケストレーション。
• Payment Service: プロバイダーと統合し、Webhookコールバックを冪等に処理。
• Ticket Service: 決済成功後に署名付きデジタルチケット（JWT/QR）を発行。
• Notification Service: メール/プッシュ（SES/SNS）。
• Waiting Room / Virtual Queue Service: オンセール時のスパイクのエントリをスロットリング。
• Expiration Worker: 10分後に未払いホールドを解放。
• Admin/Onsale Service: イベント設定、座席マップアップロード、オンセールスケジュール。

クロスファンクショナル：Kafka（MSK）イベント用、Redis（ElastiCache、クラスターモード）ホットステートとロック用、PostgreSQL（Aurora Multi-AZ）トランザクションデータ用、DynamoDB冪等キーとチケットストア用、S3座席マップJSON/画像用、OpenSearchイベント検索用。

3. データストア

• Aurora PostgreSQL（Multi-AZ、ライター1台＋リーダー2台）: イベント、ユーザー、予約、決済、チケット（記録システム）。継続的バックアップ；PITR。
• Redis Cluster（Multi-AZ、レプリカあり）: 座席ごとのホールド状態、イベントごとの座席ビットマップキャッシュ、レートリミット、待機室トークン。ホールドに対する高速CASに使用。
• DynamoDB: 決済冪等キー、Webhook重複排除、発行済みチケットルックアップ（低レイテンシ、デフォルトでマルチAZ）。
• Kafka（MSK）: ドメインイベント（SeatHeld, ReservationCreated, PaymentSucceeded, PaymentFailed, ReservationExpired, TicketIssued）。AZをまたぐレプリケーションファクター3。
• S3: 静的な座席マップアーティファクト、チケットPDF。
• CDN: イベントリスト、座席マップのスケルトンをキャッシュ（ライブ可用性ではない）。
• OpenSearch: イベント検索/フィルタリング。

4. コアデータモデル

events(event_id PK, venue_id, name, onsale_at, status, version)。
seats(seat_id PK, event_id, section, row, number, price_tier, status ENUM[available, held, reserved, sold], hold_id NULL, version BIGINT)。複合インデックス（event_id, status）。楽観的ロックのための行レベルバージョン管理。
reservations(reservation_id PK, user_id, event_id, seat_ids[], state ENUM[pending_payment, confirmed, expired, cancelled], created_at, expires_at, payment_intent_id, idempotency_key UNIQUE)。
payments(payment_id PK, reservation_id, provider_ref UNIQUE, status, amount, currency, received_at)。少なくとも1回の重複排除のためのプロバイダー参照の一意制約。
tickets(ticket_id PK, reservation_id, seat_id, qr_payload, issued_at, signature)。
outbox(id, aggregate, payload, published_at) トランザクションアウトボクシングパターン → Kafka用。

Redisキー：

• event:{id}:seat:{seat_id} → status + ホールド所有者 + TTL 600秒。
• event:{id}:availability → 高速カウント用のビットマップ/HLL。
• hold:{reservation_id} → 座席リスト、TTL 600秒。

5. コアAPI（REST + 冪等性ヘッダー）

• GET /events?filters → ページネーションされたリスト（CDNキャッシュ可能、TTL 30秒）。
• GET /events/{id} → イベント詳細。
• GET /events/{id}/seatmap → 静的なレイアウト（長期キャッシュ）。
• GET /events/{id}/availability → 大まかな可用性（セクション）；キャッシュ期間1〜5秒。
• GET /events/{id}/seats?section=A → 詳細な座席状態（短時間キャッシュまたはライブ）。
• POST /reservations (Idempotency-Key) → {event_id, seat_ids[]} → 10分間のホールドを作成。
• GET /reservations/{id} → 状態、有効期限。
• DELETE /reservations/{id} → ユーザーがキャンセルし、座席を解放。
• POST /reservations/{id}/checkout → プロバイダーで決済意図を作成し、クライアントシークレットを返す。
• POST /webhooks/payments → プロバイダーコールバック（署名付き、冪等）。
• GET /tickets/{id} → 署名付きデジタルチケット。
• 管理用：POST /events, POST /events/{id}/seats:bulk, POST /events/{id}/onsale。

6. リクエストフロー

ブラウジング

クライアント → CDN（カタログ/座席マップのヒット）→ ミスの場合、API → カタログサービス → Auroraリーダー / OpenSearch。可用性カウントはRedisから1〜5秒の遅延で提供され、個々の座席状態はユーザーが表示しているセクションに対してライブで取得される。

予約（ホールド）

1. クライアントがIdempotency-Keyと対象座席を指定してPOST /reservationsを送信。
2. API Gatewayが待機室トークンをチェックし、ユーザー/IPごとにレート制限。
3. Reservation Serviceがイベントステータスと座席IDを検証。
4. Redis Luaスクリプトによるアトミックなホールド取得：各座席キーについて、SETNXでホールドIDとTTL 600秒を設定。いずれかの座席で失敗した場合、成功したものをロールバックして競合する座席とともに409を返す。
5. Auroraにpending_payment状態で予約行を永続化（アウトボックイベントとの単一トランザクション）。座席に対する楽観的ロックを使用：UPDATE seats SET status='held', hold_id=?, version=version+1 WHERE seat_id=? AND status='available'。Auroraが耐久性のある真実であり、Redisは高速なガードである。両方が一致する必要がある。
6. expires_atとともに予約を返す。p95 < 800 ms。

決済

1. クライアントがPOST /reservations/{id}/checkoutを呼び出す。Payment ServiceがプロバイダーでPaymentIntentを作成し、provider_refを予約IDをキーとして保存（冪等）。
2. クライアントはプロバイダーSDKを介して直接決済を完了する（PCIスコープ外）。
3. プロバイダーがWebhookを送信 → POST /webhooks/payments。
4. Webhookハンドラー：署名を検証 → provider_ref UNIQUEを使用してpaymentsにupsert（重複排除）。追加の冪等性のためにDynamoDBの条件付きPutを使用。
5. succeededの場合：トランザクション更新 — 予約→confirmed、座席→sold、ticketsを書き込み、アウトボックイベントTicketIssuedを追記。順不同の安全性：ハンドラーはイベントタイムスタンプを比較し、古い遷移を無視する（ステートマシン：pending → confirmed/failed/expired、ターミナル状態は遅延重複を吸収）。
6. Ticket ServiceがTicketIssuedを消費し、署名付きQR/PDFを生成し、S3 + DynamoDBに保存。Notification Serviceがユーザーにメール送信。

期限切れ

• プライマリ：Redis TTLがhold:*キーを期限切れにする → キー空間通知がExpiration Workerをトリガー。Workerは、予約がまだpending_paymentの場合のみ座席を解放するAuroraトランザクションを実行（状態に対するCAS）。
• バックストップ：30秒ごとにスケジュールされたジョブがreservations WHERE state='pending_payment' AND expires_at < now() - 30sをスキャンして解放。
  遅延Webhook到着：座席が既に再販されている場合、決済をrefund_requiredとマークし、自動返金をトリガー。座席がまだ空いている場合、オプションで再確認 — ただしデフォルトポリシーは返金であり、再販された可能性のある座席を再ホールドできないため。決済プロバイダーの5分遅延は10分ホールドウィンドウ内に収まるため、通常のケースでは競合しない。

7. 過剰販売の防止（一貫性）

• 座席は単一の所有リソース：すべての状態遷移はAuroraで楽観的並行性を使用（WHERE status=expected_status AND version=expected_version）。
• Redis SETNXは、DBに負荷をかけずに高速な第一線での拒否（8k RPS）を提供。Auroraの行更新は第二線であり、法的な真実である。
• すべての決済側書き込みは、provider_refの一意性とDynamoDB重複排除テーブルにより冪等。
• アウトボックパターンにより、DBコミットに対してドメインイベントがKafkaにExactly-onceで発行される。
• 単一の座席行内での強い一貫性。集計可用性カウント（ブラウズビューに表示される）については、結果整合性のみが許容される。

8. スパイクに対するスケーリング戦略

• 仮想待機室：concurrent_users > thresholdの場合、新規ユーザーはキューチケットを取得。予約エンドポイントには1秒あたりNトークンのみが許可される。システムを既知の容量（例：予約試行8,000件/秒を吸収するために10,000件/秒を許可）に保つ。
• 水平オートスケーリング（EKS上のHPA）：CPUとカスタムRPSメトリクスに基づき、オンセール前に15分間ポッドを事前ウォームアップ。
• ホットイベントのシャーディング：event_idでRedisキーをパーティション化し、単一のメガイベントが専用シャードに着地するようにする。既知のオンセール用にシャードを事前プロビジョニング可能。
• 読み取りスケーリング：Auroraリードレプリカ + 可用性用のRedis + 静的データ用のCDN。
• バックプレッシャー：API Gatewayのユーザーごとのリクエストクォータ。Retry-After付きの429。
• 非同期ファンアウト：Kafkaはチケット生成、メール、分析をホットパスから分離。
• コネクションプーリング：Auroraコネクションストームを回避するためのRDS Proxy / PgBouncer。
• ボット対策：オンセール中のPOST /reservationsに対するWAF、CAPTCHA、デバイスフィンガープリンティング。

9. 信頼性とディザスタリカバリ

• すべての状態コンポーネント（Aurora、レプリカ付きRedis + 自動フェイルオーバー、MSK RF=3、DynamoDB）に対するMulti-AZ。
• Aurora：S3への継続的バックアップ、保持期間内の任意の秒へのPITR → RPO ≤ 1分達成。フェイルオーバー約30〜60秒 → RTO ≤ 15分達成。
• Redis：自動フェイルオーバー付きMulti-AZ。データはAuroraから再構築可能（ホールドはコールドスタート時にreservations WHERE state='pending_payment'から再構築可能）。
• Kafka：階層型ストレージ、RF=3、最小ISR=2。
• DRランブック：リージョン全体の障害復旧のためのクロスリージョンAurora Global Databaseレプリカ（RPO約数秒）、文書化されたプロモーション手順。
• カオスドリル：AZブラックアウト、Redisプライマリキル、決済プロバイダー障害シミュレーションを四半期ごとに実施。
• ヘルスチェック（ALBレベル）；サービス間および決済プロバイダーへのサーキットブレーカー（Resilience4jライク）。
• グレースフルデグラデーション：Redisが利用不可の場合、DBのみのパスにフォールバックし、より厳格なレート制限を適用。決済プロバイダーがダウンした場合、チェックアウトをキューに入れ、ユーザーに通知。

10. モニタリングとアラート

• メトリクス（Prometheus + CloudWatch）：エンドポイントごとのRPS、p50/p95/p99レイテンシ、予約成功率、ホールド取得競合率、決済Webhook遅延、期限切れWorker遅延、Auroraレプリカ遅延、Redis CPU/メモリ/エビクション、Kafkaコンシューマー遅延。
• SLO：オンセールウィンドウ中の99.95%の可用性。p95ブラウジング < 300 ms。p95予約 < 800 ms。エラーバジェット消費アラート。
• トレーシング：OpenTelemetryエンドツーエンド（クライアント → API → サービス → DB）。
• ロギング：CloudWatch/Elasticへの構造化JSON。相関ID。
• ビジネスダッシュボード：秒間ホールド数、コンバージョン率（ホールド→支払い）、過剰販売カウンター（0であること — 非ゼロの場合はアラート）。
• アラート：過剰販売=0違反（P0）、Webhookバックログ > 1分、予約p95が5分間 > 800 ms、Auroraフェイルオーバー、Redisフェイルオーバー、決済成功率の低下 > 2σ。

11. 主要なトレードオフと代替案

• ホールド権威としてのRedis vs. DBのみ：純粋なDBアプローチはよりシンプルで強力だが、単一行ホットスポットで8k RPSを維持できなかった。Redisファーストはスパイクを吸収し、DB行更新が正確性を保証する。
• 悲観的ロック（SELECT FOR UPDATE）：検討したが、人気のあるセクションでのロック競合がスループットを低下させるため却下。楽観的ロックとリトライの方がスケーラブル。
• 指定席 vs. 一般入場カウンター：上記の設計は座席ごと。一般入場の場合、単一のデクリメントカウンター（RedisのDECR、フロア0、DBにミラーリング）を使用する。
• 単一リージョン vs. マルチリージョンアクティブ/アクティブ：制約により1リージョン。アクティブ/アクティブは「決して売り切らない」を複雑にする（クロスリージョンコンセンサスが必要）。DRのためにクロスリージョンリードレプリカのみを使用。
• Kafka vs. SQS：順序付けられ、リプレイ可能なイベントログ（順不同の決済処理や状態再構築に役立つ）のためにKafkaを選択。
• 同期決済 vs. Webhookのみ：PCIライトを維持し、プロバイダーの遅延に耐えるためにWebhookのみを選択。Webhookの遅延（最大5分）は10分ホールドウィンドウ内に収まる。
• 待機室 vs. 純粋なオートスケーリング：オートスケーリングだけではステートフルストアを保護できない。キューは決定論的なロード形状を提供し、大量の503エラーよりも優れたユーザーエクスペリエンスを提供する。
• チケットの同期発行 vs. 非同期：Kafkaを介した非同期発行により、決済コールバックハンドラーは高速かつ回復力を持つ。ユーザーはプッシュ/リフレッシュを通じて数秒以内にチケットを確認できる。

この設計は、述べられたSLOを満たし、レイヤ化された楽観的並行性により過剰販売を防ぎ、仮想キュー+Redisフロントエンドホールドによりオンセールスパイクを吸収し、PITRとリハーサル済みフェイルオーバーを備えたMulti-AZマネージドストアを通じてRPO/RTOターゲットを満たします。

システム設計：スケーラブルなコンサートチケット予約システム

1. 主要サービスとデータストア

サービス:

• API Gateway: 全てのクライアントリクエストのエントリポイント。認証、レート制限、リクエストルーティングを処理します。
• User Service: ユーザー登録、プロフィール、認証を管理します。
• Event Service: イベントの詳細、スケジュール、静的コンテンツを管理します。
• Seat Service: イベントの座席在庫、空き状況、座席マップデータを管理します。
• Reservation Service: 座席予約ロジックを処理し、予約のライフサイクル（保留中、確定、期限切れ）を管理します。
• Payment Service (内部): 外部決済プロバイダーとの連携をオーケストレーションし、コールバックを処理し、内部決済記録を管理します。
• Notification Service: デジタルチケット、確認メール、その他のユーザー通知を送信します。
• Queueing Service (Kafka): サービス間の非同期通信、高スループットイベント（例：決済コールバック、予約期限切れ）を処理します。
• Cache Service (Redis): 座席の空き状況、イベント詳細、分散ロックへの高速データアクセスを提供します。
• Background Worker Service: 予約期限切れ、決済コールバックの再試行、データクリーンアップなどの非同期タスクを処理します。

データストア:

• PostgreSQL (リレーショナルデータベース): ユーザー、イベント、座席、予約、決済のプライマリデータストア。過剰販売を防ぐために不可欠な強力なACID特性のために選択されました。
  • デプロイメント: マルチAZ、プライマリ-レプリカ構成。同期レプリケーション（クリティカルテーブル：座席、予約）と非同期レプリケーション（その他）。
• Redis (インメモリデータストア): 以下に使用されます。
  • 座席の空き状況とイベント詳細のキャッシュ。
  • 座席予約と確定のための分散ロック。
  • 一時的な予約期限切れタイマー（TTLキー）。
• Kafka (分散ストリーミングプラットフォーム): 信頼性の高い非同期メッセージングとイベントソーシングのため。
• オブジェクトストレージ (例: S3): イベント画像、アーティスト写真、および潜在的なデジタルチケットPDFなどの静的アセットを保存します。

2. コアAPI

User Service:

• POST /users/register: 新規ユーザー登録。
• POST /users/login: ユーザー認証。
• GET /users/{id}: ユーザープロファイル取得。

Event Service:

• GET /events: 全イベントを閲覧（ページネーション）。
• GET /events/{id}: 特定イベントの詳細取得。
• GET /events/{id}/seatmap: イベントの座席マップと現在の空き状況取得。

Reservation Service:

• POST /events/{id}/reserve: イベントの特定座席を予約。入力: event_id, seat_ids, user_id。出力: reservation_id, expires_at。
• GET /reservations/{id}: 予約詳細取得。
• DELETE /reservations/{id}: 保留中の予約をキャンセル。
• POST /reservations/{id}/confirm: 決済成功後の予約確定（内部API、Payment Serviceによってトリガー）。

Payment Service:

• POST /payments/initiate: 予約の決済を開始。入力: reservation_id, amount, user_id。出力: 決済プロバイダーのリダイレクトURL。
• POST /payments/callback: 外部決済プロバイダーのコールバック用Webhookエンドポイント（内部）。

Ticket Service (Notification/Reservation Serviceの一部):

• GET /tickets/{id}: デジタルチケット取得。

3. 座席と予約のデータモデル

テーブル: users

• user_id (PK, UUID)
• username (VARCHAR, UNIQUE)
• email (VARCHAR, UNIQUE)
• password_hash (VARCHAR)
• created_at (TIMESTAMP)

テーブル: events

• event_id (PK, UUID)
• name (VARCHAR)
• venue (VARCHAR)
• date_time (TIMESTAMP)
• total_seats (INT)
• image_url (VARCHAR)

テーブル: seats

• seat_id (PK, UUID)
• event_id (FK to events.event_id)
• section (VARCHAR)
• row_number (VARCHAR)
• seat_number (VARCHAR)
• price (DECIMAL)
• status (ENUM: 'available', 'reserved', 'sold')
• version (INT, 楽観的ロック用)

テーブル: reservations

• reservation_id (PK, UUID)
• user_id (FK to users.user_id)
• event_id (FK to events.event_id)
• status (ENUM: 'pending', 'confirmed', 'expired', 'cancelled')
• reserved_at (TIMESTAMP)
• expires_at (TIMESTAMP)
• payment_id (FK to payments.payment_id, nullable)
• total_amount (DECIMAL)
• created_at (TIMESTAMP)
• updated_at (TIMESTAMP)

テーブル: reservation_seats (ジャンクションテーブル)

• reservation_id (FK to reservations.reservation_id)
• seat_id (FK to seats.seat_id)
• (複合PK: reservation_id, seat_id)

テーブル: payments

• payment_id (PK, UUID)
• reservation_id (FK to reservations.reservation_id)
• user_id (FK to users.user_id)
• amount (DECIMAL)
• currency (VARCHAR)
• provider_transaction_id (VARCHAR, UNIQUE)
• status (ENUM: 'initiated', 'pending', 'succeeded', 'failed', 'refunded')
• created_at (TIMESTAMP)
• updated_at (TIMESTAMP)

4. リクエストフロー

A. イベントの閲覧と座席空き状況の確認:

1. ユーザーリクエスト: ユーザーのブラウザ/アプリが /events または /events/{id}/seatmap をリクエスト。
2. CDN: キャッシュされていれば静的アセット（イベント画像、JS/CSS）を提供。
3. API Gateway: ユーザー認証、リクエストをEvent ServiceまたはSeat Serviceにルーティング。
4. Event Service: PostgreSQL（またはRedisキャッシュ）からイベント詳細を取得。
5. Seat Service: Redisキャッシュから座席マップと空き状況を取得。キャッシュにない場合は、PostgreSQL seats テーブルをクエリし、キャッシュを更新してデータを返す。
6. レスポンス: ユーザーにデータが返される。（P95レイテンシ < 300 ms）。

B. 座席の予約:

1. ユーザーリクエスト: ユーザーが座席を選択し、「予約」をクリック。event_id, seat_ids, user_id を含む POST /events/{id}/reserve を送信。
2. API Gateway: Reservation Serviceにルーティング。
3. Reservation Service:
   • 分散ロック: 各 seat_id に対してRedisで分散ロックを取得し、同時変更を防ぐ。（例: LOCK:seat:{seat_id}）。
   • 座席ステータスチェック: seats テーブル（またはRedisキャッシュ）をクエリして、選択された座席が「available」であることを確認。
   • トランザクション: データベーストランザクションを開始。
   • 座席更新: seats テーブルの選択された座席の status を「reserved」に更新。
   • 予約作成: reservations テーブルに status='pending', reserved_at, expires_at（現在時刻 + 10分）を持つ新しいレコードを挿入。
   • 座席リンク: 各予約済み座席に対して reservation_seats にレコードを挿入。
   • トランザクションコミット。
   • Redis TTL設定: 10分間のTTLを持つRedisキー（例: RESERVATION_EXPIRY:{reservation_id}）を設定。これは高速な期限切れトリガーとして機能。
   • ロック解放: 座席の分散ロックを解放。
4. レスポンス: reservation_id と expires_at をユーザーに返す。（P95レイテンシ < 800 ms、決済を除く）。

C. 予約の決済:

1. ユーザーアクション: ユーザーが pending 予約の決済を開始。
2. ユーザーリクエスト: ブラウザ/アプリが reservation_id を含む POST /payments/initiate を Payment Service に送信。
3. Payment Service (内部):
   • status='initiated' で payment レコードを作成。
   • 外部決済プロバイダーAPI（例: Stripe, PayPal）を予約詳細と金額で呼び出す。
   • ユーザーを決済プロバイダーのページにリダイレクト。
4. 外部決済プロバイダー: 決済を処理。
5. 決済プロバイダーコールバック: 決済成功/失敗後、外部プロバイダーは非同期Webhook POST /payments/callback を Payment Service に送信。
6. Payment Service (内部) - コールバックハンドラー:
   • 冪等性チェック: provider_transaction_id を使用して、コールバックが一度だけ処理されることを保証。
   • payment レコードのステータスを更新（succeeded または failed）。
   • PaymentConfirmed または PaymentFailed イベントをKafkaに発行。reservation_id と payment_id を含む。
7. Reservation Service - Kafkaコンシューマー:
   • PaymentConfirmed イベントを消費。
   • 分散ロック: reservation_id のロックを取得。
   • トランザクション: データベーストランザクションを開始。
   • 予約更新: reservations テーブルを更新: status='confirmed', payment_id をリンク。
   • 座席更新: seats テーブルの関連座席の status を「sold」に更新。
   • トランザクションコミット。
   • Redis TTL削除: Redisから RESERVATION_EXPIRY:{reservation_id} キーを削除。
   • ロック解放。
   • TicketIssued イベントをKafkaに発行。
8. Notification Service - Kafkaコンシューマー: TicketIssued イベントを消費し、デジタルチケットを生成してユーザーにメール/プッシュ通知を送信。

D. 予約の期限切れ:

1. Redis Keyspace Events / バックグラウンドワーカー:
   • 高速パス (Redis TTL): RESERVATION_EXPIRY:{reservation_id} キーがRedisで期限切れになると、keyspaceイベントがトリガーされる。専用のマイクロサービスまたはバックグラウンドワーカーがこのイベントを消費。
   • 堅牢パス (DBスキャン): バックグラウンドワーカーサービスが定期的に（例：30秒ごと）reservations テーブルをスキャンし、status='pending' かつ expires_at < 現在時刻 のレコードを探す。
2. バックグラウンドワーカーロジック:
   • 期限切れの pending 予約ごとに:
     • 分散ロック: reservation_id のロックを取得。
     • ステータスチェック: 予約がまだ pending であることを確認（競合状態や遅延イベントにより、既に決済済みの予約が期限切れになるのを防ぐため）。
     • トランザクション: データベーストランザクションを開始。
     • 予約更新: reservations テーブルを更新: status='expired'。
     • 座席更新: seats テーブルの関連座席の status を「available」に戻す。
     • トランザクションコミット。
     • ロック解放。

5. トラフィック急増へのスケーリング戦略

• ステートレスサービス: 全てのアプリケーションサービス（User, Event, Seat, Reservation, Payment, Notification）はステートレスに設計されており、水平スケーリングが可能。
• オートスケーリンググループ (ASG): CPU使用率、リクエストキュー深度、カスタムメトリクス（例：アクティブな予約数）などのメトリクスに基づいて、インスタンスを自動的に追加/削除するASGにサービスをデプロイ。
• ロードバランサー: アプリケーションロードバランサー（ALB）が、複数のアベイラビリティゾーンにまたがる各サービスの健全なインスタンスに受信トラフィックを分散。
• CDN: 静的アセット（イベント画像、JS、CSS）をキャッシュし、バックエンドサービスへのトラフィックをオフロードし、ユーザーのレイテンシを削減。
• キャッシング (Redis): 頻繁にアクセスされるデータ（座席空き状況、イベント詳細）のRedisによる広範なキャッシュ利用は、特に読み取り負荷の高いブラウジングや座席マップ表示中に、データベース負荷を大幅に削減。
• キュー (Kafka): Kafkaはバッファーとして機能し、サービスを疎結合にし、トラフィックの急増を吸収する。非同期操作（決済コールバック、通知、予約期限切れ処理）はKafkaにプッシュされ、サービスはユーザーリクエストをブロックすることなく自身のペースで処理できる。
• データベースリードレプリカ: PostgreSQLインスタンスは複数のリードレプリカで構成。読み取り負荷の高いサービス（Event Service, 座席マップ用のSeat Service）はこれらのレプリカにクエリを指示し、プライマリデータベースの負荷をオフロードできる。
• データベースシャーディング (将来の可能性): 単一のPostgreSQLインスタンスが書き込みのボトルネックになった場合、event_id または user_id によるシャーディングを検討できる。これは、複数のデータベースインスタンスにデータを分散させることを意味する。
• コネクションプーリング: オーバーヘッドを最小限に抑え、スループットを最大化するための効率的なデータベース接続管理。
• レート制限: API Gatewayで実装され、不正なトラフィックや突然の圧倒的なスパイクからバックエンドサービスを保護。

6. 信頼性と災害復旧アプローチ

• マルチアベイラビリティゾーン (Multi-AZ) デプロイメント: 全てのサービスとデータストアは、クラウドリージョン内の少なくとも3つのアベイラビリティゾーンにデプロイされる。これにより、AZレベルの障害に対する耐性が提供される。
• データベースレプリケーションとフェイルオーバー:
  • PostgreSQL: プライマリ-レプリカ構成。クリティカルデータ（座席、予約）は同期レプリケーションを使用し、RPO < 1分を保証。プライマリ障害発生時には、レプリカをプライマリに昇格させる自動フェイルオーバーメカニズム（例：Patroni、クラウドマネージドRDSフェイルオーバー）により、RTO < 15分を達成。
  • Redis: 高可用性のためのSentinelまたはClusterモード。異なるAZのノード間でデータがレプリケートされる。
• Kafkaの耐久性: Kafkaブローカーは複数のAZにデプロイされ、レプリケーション係数 > 1（例：3）で、AZまたはブローカーが失敗した場合でもメッセージの耐久性と可用性を保証。
• 自動バックアップ: PostgreSQLの定期的な自動バックアップをオブジェクトストレージに保存し、ポイントインタイムリカバリ機能を備える。Redisのスナップショット。
• ステートレスサービス: サービスはステートレスに設計されており、どのインスタンスもデータ損失なしに交換または再起動できるため、高可用性に貢献。
• サーキットブレーカーとリトライ: サービス間通信に実装され、カスケード障害を防ぐ。失敗したリクエストは、サービスが正常に低下するか、リトライする。
• グレースフルデグラデーション: 極端な負荷時には、コア機能（予約、決済）を優先するために、非クリティカルな機能（例：パーソナライズされた推奨）が一時的に無効になる場合がある。
• 目標復旧時間 (RPO) < 1分: クリティカルデータの同期データベースレプリケーションと、適切なレプリケーション設定を持つKafkaの耐久性のあるメッセージロギングにより達成。
• 目標復旧時間 (RTO) < 15分: 自動データベースフェイルオーバー、アプリケーションサービスのオートスケーリング、およびウォームアップ済みインスタンスまたは迅速なプロビジョニング機能により達成。

7. 過剰販売を防ぐための整合性選択

過剰販売を防ぐことは最優先事項であり、座席ステータスの更新には強力な整合性が必要。

• 分散ロック (Redis): ユーザーが座席を予約しようとすると、Reservation ServiceはRedisで各特定の seat_id の分散ロックを取得する。これにより、一度に1つの予約試行のみが特定の座席のステータスを変更できることが保証される。ロックは、座席ステータスを更新し予約を作成するデータベーストランザクションの期間保持される。
• ACIDトランザクション (PostgreSQL): seats ステータスの全ての更新と reservations レコードの作成/更新は、PostgreSQL内の単一のACIDトランザクション内で実行される。これにより、原子性、整合性、分離性、永続性が保証される。トランザクションのいずれかの部分が失敗した場合（例：別のユーザーが既に座席を予約した場合）、トランザクション全体がロールバックされ、部分的な更新がなくなり、過剰販売が防止される。
• 楽観的並行性制御 (バージョン番号): seats テーブルには version 列を追加できる。座席ステータスを更新する際、UPDATE クエリには WHERE version = <old_version> が含まれる。バージョンが一致しない場合、それは別のトランザクションが座席を変更したことを意味し、現在のトランザクションはリトライまたは拒否できる。これは、分散ロックが失敗した場合や完全に実装されていない場合でも、競合状態に対する追加の保護層を提供する。
• 冪等な決済処理: 決済プロバイダーのコールバックは at-least-once であり、順不同の場合がある。Payment Serviceはこれらのコールバックを冪等に処理し、provider_transaction_id を使用して、成功した決済が予約に一度だけ適用されることを保証し、二重確認や不正確なステータス更新を防ぐ。
• 予約期限切れロジック: 期限切れプロセスは、期限切れマークを付けて座席を解放する前に、予約がまだ pending であるかどうかを明示的にチェックする。これにより、期限切れプロセスが実行されようとしているときに決済が到着する競合状態を防ぐ。

8. モニタリングとアラート

• メトリクス収集: 全てのサービス、データベース、キャッシュ、キューからメトリクスを収集するためにPrometheus/Grafanaまたはクラウドネイティブ監視（例：CloudWatch, Stackdriver）を使用。主要メトリクス:
  • システムメトリクス: CPU使用率、メモリ使用量、ディスクI/O、ネットワークI/O。
  • アプリケーションメトリクス: リクエストレート、エラーレート（5xx）、レイテンシ（p95, p99）（全てのAPIエンドポイント）、キュー深度、アクティブ接続数、ガベージコレクション。
  • データベースメトリクス: クエリレイテンシ、接続プール使用率、トランザクションレート、レプリケーションラグ、デッドロック。
  • キャッシュメトリクス: キャッシュヒット/ミス率、メモリ使用量。
  • Kafkaメトリクス: プロデューサー/コンシューマーラグ、メッセージレート、ブローカーヘルス。
• 集中ログ記録: 全てのサービスからのログを集中ログシステム（例：ELKスタック、Splunk、Datadog）に集約。解析を容易にするために構造化ログを使用。
• 分散トレーシング: 複数のサービスにわたるリクエストフローを視覚化し、ボトルネックを特定し、複雑なインタラクションをデバッグするために分散トレーシング（例：OpenTelemetry, Jaeger）を実装。
• アラート: クリティカルな閾値に対してアラートを設定:
  • 高エラーレート（例：5分間で5%の5xxエラー）。
  • 高レイテンシ（例：p95 APIレイテンシ > 800ms）。
  • サービスダウンタイムまたはヘルスチェック失敗インスタンス。
  • データベースレプリケーションラグが閾値を超える。
  • キューのバックログ。
  • 決済コールバックまたは予約期限切れの失敗。
  • リソース枯渇（CPU、メモリ、ディスク）。
• ダッシュボード: 運用可視性のためのリアルタイムダッシュボードを作成し、主要メトリクスとサービスヘルスを表示。

9. 主要なトレードオフまたは代替案

• データベース選択:
  • 代替案: NoSQLデータベース（例：Cassandra, DynamoDB）で極端な書き込みスケーラビリティを実現。 トレードオフ: NoSQLは大量のスケールを処理できるが、座席予約のような複数の更新とチェックを伴う複雑なトランザクション操作で強力な整合性を達成するのは著しく困難であり、しばしば複雑なアプリケーションレベルのロジックが必要となる。PostgreSQLのACID特性は過剰販売防止を簡素化し、そのスケーラビリティはリードレプリカとシャーディングを通じて管理できる。
• ロッキングメカニズム:
  • 代替案: データベースレベルの行ロック。 トレードオフ: 高同時実行シナリオでの競合やデッドロックの原因となり、パフォーマンスに影響を与える可能性がある。Redis分散ロックは一般的に高速であり、ロッキングメカニズムをデータベースからオフロードするが、慎重な実装（例：ロック期限切れの処理、ロック取得/解放の原子性の保証）が必要。
• 予約期限切れ:
  • 代替案: Redis TTL keyspaceイベントに完全に依存。 トレードオフ: 高速だが、Redis keyspaceイベントは配信が保証されない（例：Redisの再起動やイベントの欠落）。選択されたアプローチは、高速パスのためにRedis TTLと、最終的な整合性を確保するためにデータベースをスキャンする堅牢なバックグラウンドワーカーを組み合わせ、予約が pending のまま永久にスタックしないことを保証する。
• 決済コールバック処理:
  • 代替案: 決済プロバイダーからの同期コールバック。 トレードオフ: これは外部プロバイダーからはほとんど提供されず、プラットフォームが高可用性で決済プロバイダーに応答する必要があり、タイトな結合が生じる。Kafkaを介した非同期の at-least-once アプローチは標準的でより回復力があるが、冪等処理と順不同メッセージの処理が必要。
• マイクロサービス vs モノリス:
  • 代替案: モノリシックアーキテクチャ。 トレードオフ: 初期開発はシンプルだが、個々のコンポーネントのスケーリング、独立したデプロイ、大規模チームでの管理が困難になる。マイクロサービスは、より良いスケーラビリティ、障害分離、技術的多様性を提供するが、運用上の複雑さ（分散トランザクション、監視、デプロイ）が増加する。

10. 前提条件

• ユーザー認証: ユーザーは、座席予約やチケット表示など、IDを必要とするアクションを実行する前に認証される。
• PCIコンプライアンス: 外部決済プロバイダーが全てのPCI DSSコンプライアンス要件を処理する。内部Payment Serviceは、最小限の非機密決済データをオーケストレーションおよび保存するのみ。
• クラウドリージョン容量: 選択されたクラウドリージョンは、指定されたピーク負荷を処理するのに十分なコンピューティング、ネットワーク、ストレージ容量を持つと仮定。
• ネットワークレイテンシ: クラウドリージョン内の内部ネットワークレイテンシおよびアベイラビリティゾーン間のレイテンシは、レイテンシターゲットを満たすのに十分低いと仮定。
• セキュリティ: 標準的なセキュリティプラクティス（例：転送中および保存中の暗号化、入力検証、アクセス制御、脆弱性スキャン）はシステム全体に実装されているが、この設計では詳細を省略。
• 外部決済プロバイダーの信頼性: 外部決済プロバイダーは、決済処理とコールバック送信において高い可用性と信頼性を持つと仮定。