スーパーボウルのチケット発売時の熱狂をTicketmasterが崩壊せずに耐え抜く理由をご存じですか？
システム設計の面接では、Ticketmasterのようなチケット予約システムを設計するのは単なる演習ではありません——大規模なカオスを制御するための短期集中講座です。こんな場面を想像してください：1000万人のユーザーがサーバーを叩きつけ、最後の席を狙うのです。読み込み中心のワークロード（100:1の比率）、500ms未満の検索、そして悪夢の二重予約を回避するための鉄壁の一貫性です。
ポイントはここです。まず要件をしっかり固めます。機能要件？ ユーザーがイベントを閲覧し、検索し、チケットを予約する。それがコアの3つです。あとは管理者が公演を追加したり、热门コンサートのダイナミックプライシングなど、出スコープとして脇に置いて集中します。ただし、軽く触れておくとプロダクトのセンスが光ります。
非機能要件？ メガイベント向けのスケーラビリティ。閲覧時の可用性、予約時の整合性。低レイテンシ。そして読み込み中心なので、DBはクエリ攻撃に耐えられるよう設計します。
面接を救う要件の優先順位付け
容赦なく優先順位を付けます。面接官は集中力を評価します。
ユーザーはイベントを閲覧できます。ユーザーはイベントを検索できます。ユーザーはイベントのチケットを予約できます。
（これは設計図からのものです：ユーザーがイベントを閲覧・検索・予約。翻訳して自分のものにしてください。）
出スコープですが賢く触れる点：予約履歴の閲覧、主催者のイベントアップロード、サージプライシング。面接官に確認を——「これらを追加しますか？」機敏さをアピールします。
非機能要件が深みを生みます。イベントあたり1000万人？ シャーディング必須。<500ms検索？ キャッシュを大量投入。二重予約なし？ 書き込み時の強整合性。
戦略？ 機能要件を順に扱い、非機能で詳細を掘り下げます。溺れないように。
コアエンティティ：チケットマジックの構成要素
イベント、ユーザー、パフォーマー、会場、チケット、予約。シンプルですね？
Event：日付、説明、タイプ、アーティスト/チーム。
User：あなた自身、予約熱狂の参加者。
Performer：名前、バイオ、リンク——スターの魅力。
Venue：住所、収容人数、座席マップ（インタラクティブ選択のためのJSONマジック）。
Ticket：イベントID、座席詳細（セクション/行/番号）、価格、ステータス（available/sold）。イベント公開時に会場マップごとに事前作成。
Booking：ユーザーID、チケットリスト、合計金額、ステータス。トランザクション安全のためTicketと分離——統合すればレースコンディションの餌食です。
座席マップはVenueが保持。クライアントがチケットステータスを重ねてレンダリング。インタラクティブ座席セレクターです。鮮やかでしょう？ 星座から星を選ぶようなもの。
ただし、オリジナル設計はここで切れます。未来志向にしましょう。
殺到対応：ブラックフライデー級のスケーラビリティ
1000万人。ピーク負荷。モノリスは泣きます。
マイクロサービスへ。閲覧/検索用のイベントサービス、トランザクション用の予約サービス。
データベース？ イベントデータ：リードレプリカを満載。CassandraやDynamoDBで水平スケール——閲覧なら最終整合性でOK。
チケット/予約？ イベントIDでPostgreSQLをシャーディング。あるいはMySQLのVitessでシャーディング。書き込みは強ACID。
キャッシング？ 热门イベント/座席にRedisクラスター。予約時に賢く無効化。
検索？ Elasticsearch。<500ms？ 可用性チェックにBloomフィルタ。
キュー？ 予約インテントにKafkaやSQS。非同期処理で座席を10分仮押さえ。
ロードバランサー→APIゲートウェイ→サービス。会場マップはCDN。
二重予約地獄？ チケットに楽観的ロック（バージョン番号）。あるいは悲観的DBロック。热门イベントはRedis/ZKで分散ロック。
ダイナミックプライシングは出スコープ？ ふん。本番ではMLモデルで価格急騰——需要を天気予報士のように予測するAIシフトです。
短いパラ。ドン。
広がり：90年代の航空戦争を想像——Sabreシステムがメインフレームで数百万フライトを毎日処理。独自の見解：TicketmasterのDNAはこれに通じます。Sabreはルートで先駆けシャーディング、ここではイベント/会場で。歴史は韻を踏みますが、今はクラウドネイティブ——Kubernetes自動スケール、サーバーレスバースト。大胆予測：AIエージェントがドロップ前にチケットを狙い撃ち、CAPTCHA進化やブロックチェーン由来を強いる。ハイプ？ いや、必然のプラットフォームシフトです。
Ticketmaster設計がシステム面接を制す理由
開発者はこれをググって準備。答え：エンドツーエンド思考をテスト——API（イベント用REST/GraphQL、POST /bookings）から容量計画（100:1 R/Wで1000 QPS読み込み、10書き込みピーク）まで。
ざっくり計算：1000万人、1%コンバージョン？ 10万予約。予約あたり10枚で100万枚。シャードに分散。
障害モード？ 回路ブレーカー。ジッタ付きリトライ。ジオレプリケーション。
出スコープの宝石：GDPR、PCI-DSS、バックアップ。触れると面接官うなずきます。
熱量を込めて。これは暗記ではなく、夢を設計するのです。コンサートはこれなしでは生まれません。
トレードオフが人間味。予約テーブル単一？ クエリ簡単、ハットスポット地獄。イベントごと分離？ スケール勝ち、結合痛。
一文。終わり。
深呼吸。エンティティ、スケールをカバー。APIスケッチ？
GET /events?search=swift&date=2024
GET /events/{id}/seats?section=A
POST /bookings {userId, ticketIds, payment}
分散トランザクションにSagaパターン：座席仮押さえ、決済、確定——失敗時は補償。
未来の驚異：AIコパイロットがこれを設計？ すぐそこ。でもまず手動マスター。
次のバイラルイベントにチケットシステムは耐えうるか？
テストを。Netflix流カオスエンジニアリング。障害注入、トラフィックスパイク。
会場座席マップはVRへ進化。でも基本は不変。
テンポよく締め。設計図は手に入りました。面接を制覇せよ。
🧬 関連インサイト
- 詳細： NotionSafe: Automating Backups So You Never Forget Again
- 詳細： Cloudflare Slaps Back at Italy’s Piracy Shield Madness
よくある質問
Ticketmasterのシステム設計面接では何を問われるか？
機能要件（閲覧/検索/予約）、非機能要件（スケーラビリティ、レイテンシ、整合性）、エンティティ、高レベルアーキテクチャ（DB/キャッシュ/キュー）。
チケットシステムで二重予約を防ぐには？
楽観的/悲観的ロック、分散ロック、キューによる短時間予約。
高読み込みチケット予約に適したデータベースは？
イベント用にCassandra/Dynamo、チケット/予約用にシャードPostgreSQL、Redisキャッシュ、ES検索。
