グローバルなURL短縮サービスの設計

1. ハイレベルアーキテクチャとリクエストフロー:

主要コンポーネント:

• APIゲートウェイ/ロードバランサー: 全てのユーザーリクエストのエントリポイントであり、ルーティング、認証、レート制限を処理します。
• 短縮サービス: 短縮URLの作成、更新、削除を担当するマイクロサービスです。カスタムエイリアスの検証と有効期限のロジックを処理します。
• リダイレクトサービス: 高スループット、低レイテンシのリダイレクトに最適化されたマイクロサービスです。クリックイベントを記録します。
• 分散キャッシュ (例: Redis Cluster): short_codeからlong_urlへのマッピングのプライマリストレージであり、最小限のレイテンシでリダイレクトを提供します。
• 分散SQLデータベース (例: CockroachDB, Google Spanner): 全てのリンクメタデータの信頼できる情報源を格納し、グローバルな一意性と強い一貫性を保証します。
• メッセージキュー (例: Apache Kafka): リダイレクトサービスからの大量のクリックイベントを取り込み、分析処理から分離します。
• 分析プロセッサ (例: Apache Flink/Spark Streaming): メッセージキューからクリックイベントを消費し、リアルタイム集計を実行し、データを格納します。
• データウェアハウス (例: ClickHouse, Snowflake, BigQuery): レポート作成と分析のために、生データと集計済み分析データを格納します。
• CDN (例: Cloudflare, Akamai): 静的アセットを配信し、グローバルDNS解決を提供し、最寄りのデータセンターへのジオルーティングを提供できます。

リクエストフロー:

• 短縮URLの作成:
  1. ユーザー/クライアントがAPIゲートウェイにリクエストを送信します。
  2. APIゲートウェイがロードバランサーにルーティングし、次に短縮サービスにルーティングします。
  3. 短縮サービスがユニークなshort_codeを生成します（またはカスタムエイリアスを検証します）。
  4. 分散SQLデータベースにshort_code、long_url、expires_at、その他のメタデータを格納します。
  5. 新しいshort_codeからlong_urlへのマッピングを分散キャッシュにプッシュします。
  6. 短縮サービスがshort_codeをユーザーに返します。
• 短縮URLのリダイレクト:
  1. ユーザー/クライアントが短縮URLにアクセスし、CDN/GeoDNS経由で最寄りのデータセンターのロードバランサーにルーティングされます。
  2. ロードバランサーがリダイレクトサービスに指示します。
  3. リダイレクトサービスはまず分散キャッシュでshort_codeからlong_urlへのマッピングを確認します。
  4. キャッシュヒット: 見つかり、アクティブな場合、HTTP 301/302リダイレクトをlong_urlに直ちに発行します。
  5. キャッシュミス: 見つからない場合、分散SQLデータベースに問い合わせます。見つかり、アクティブな場合、キャッシュを更新してからリダイレクトします。見つからない、期限切れ、または削除されている場合は、404エラーを返します。
  6. 非同期的に、リダイレクトサービスはクリックイベント（short_code、timestamp、country、device_type、referrer_domainを含む）をメッセージキューに発行します。
• 分析処理:
  1. 分析プロセッサがメッセージキューからクリックイベントを消費します。
  2. リアルタイム処理（例: 集計、エンリッチメント）を実行します。
  3. 生データと集計済みデータは、レポート作成のためにデータウェアハウスに格納されます。

2. データモデルとストレージの選択:

• リンクとエイリアス (分散SQLデータベース - CockroachDB/Google Spanner):

  • linksテーブル:
    • short_code (VARCHAR, 主キー): ユニークな短い識別子。
    • long_url (VARCHAR): 元のURL（最大500バイト）。
    • user_id (UUID, インデックス付き, FK): オプション、リンクの所有権用。
    • created_at (TIMESTAMP): リンクが作成された日時。
    • expires_at (TIMESTAMP, NULL許容, インデックス付き): リンクの有効期限日時。
    • status (ENUM: 'active', 'expired', 'deleted', インデックス付き): リンクの現在の状態。
    • is_custom_alias (BOOLEAN): ユーザー定義のエイリアスの場合はTrue。
    • click_count (BIGINT): クリック数の非正規化された、最終的に整合性の取れるカウント（分析によって更新）。
  • 正当性: short_codeとcustom_aliasのグローバルな一意性、ACID特性、ネイティブなマルチリージョンレプリケーション機能に対する強い一貫性保証のために選択されました。これにより、グローバルなデータ管理が簡素化され、データ整合性が確保されます。

• 分析イベント (メッセージキュー - Apache Kafka, データウェアハウス - ClickHouse/Snowflake):

  • Kafkaトピック (click_events): 生のクリックイベントメッセージ（例: JSON/Protobuf）を格納します。
  • データウェアハウス (raw_clicksテーブル):
    • event_id (UUID, 主キー)
    • short_code (VARCHAR, インデックス付き)
    • timestamp (TIMESTAMP, インデックス付き)
    • country (VARCHAR, インデックス付き)
    • device_type (VARCHAR)
    • referrer_domain (VARCHAR)
  • データウェアハウス (aggregated_clicksテーブル): （例: 時間ごと/日ごとの集計）
    • short_code (VARCHAR, PK)
    • aggregation_time (TIMESTAMP, PK)
    • country (VARCHAR, PK)
    • total_clicks (BIGINT)
  • 正当性: Kafkaは高スループットで耐障害性のある取り込みと分離を提供します。ClickHouse/Snowflakeは、大量のデータに対する分析クエリに最適化されており、分析の最終的な整合性要件をサポートします。

3. 読み取り負荷の高いトラフィックのスケーリング戦略:

• 分散キャッシュ (Redis Cluster): これはリダイレクトの主要なスケーリングレイヤーです。short_codeからlong_urlへのマッピングをメモリに格納し、1日あたり40億件のリダイレクトの大部分を処理します。Redis Clusterは、シャーディングとレプリケーションを通じて水平スケーリングと高可用性を提供します。
• グローバルCDNとジオルーティング: CDN（例: Cloudflare）は静的アセットを提供し、インテリジェントなDNSベースのルーティング（GeoDNS）を提供して、ユーザーを地理的に最も近いデータセンターに誘導し、リダイレクトレイテンシを最小限に抑えます。
• ステートレスサービス: 短縮サービスとリダイレクトサービスのどちらもステートレスに設計されており、各リージョンでロードバランサーの後ろにインスタンスを追加することで容易に水平スケーリングできます。オートスケーリンググループは、トラフィックに基づいて動的に容量を調整します。
• データベースリードレプリカ/分散読み取り: 分散SQLデータベースは、クラスター全体での分散読み取りをネイティブに処理します。キャッシュヒット率が予想より低い場合、またはあまり人気のないリンクの場合は、データベースがクラスター全体で読み取りをスケーリングする能力が重要になります。
• 短縮コード生成: 大量のリンク作成の場合、短縮コードはバッチで事前に生成して格納するか、分散ID生成サービス（例: Twitter Snowflakeにインスパイアされたもの）を使用して、ユニークで非シーケンシャルなコードを保証し、データベースのホットスポットを防ぐことができます。

4. 信頼性戦略:

• フェイルオーバー:
  • マルチリージョンデプロイメント: 全てのクリティカルなサービス（短縮、リダイレクト、データベース、キャッシュ、メッセージキュー）は、少なくとも3つの地理的に離れたリージョン（例: 北米、ヨーロッパ、アジア）でアクティブ-アクティブ構成でデプロイされます。
  • サービスレベルのフェイルオーバー: 各リージョン内の複数のアベイラビリティゾーンにまたがって、サービスはオートスケーリンググループでデプロイされます。ロードバランサーは、正常でないインスタンスを自動的に検出し、トラフィックをそちらにルーティングします。
  • データベースフェイルオーバー: 分散SQLデータベースは、ノードやゾーン全体が障害を起こした場合でも継続的な運用を保証するために、組み込みのマルチリージョンレプリケーションと自動フェイルオーバーメカニズム（例: CockroachDBのRaftコンセンサス）を提供します。
  • キャッシュフェイルオーバー: Redis Clusterは、データの冗長性とマスターノードの自動フェイルオーバーのためのレプリケーションを提供します。
  • メッセージキューフェイルオーバー: Kafkaクラスターは、ブローカー障害を許容するために、複数のアベイラビリティゾーンにまたがるレプリケーション（例: 3ブローカー、レプリケーションファクター3）でデプロイされます。
• 一貫性に関する決定:
  • 強い一貫性（リンク作成/エイリアス）: 分散SQLデータベースは、short_codeとcustom_aliasの一意性に対して強い一貫性を保証します。これは、衝突を防ぎ、データ整合性を維持するために不可欠です。
  • 最終的な一貫性（リダイレクト）: 分散キャッシュは、最終的な一貫性で動作します。リンクが作成、更新（例: expires_atの変更）、または削除されると、キャッシュ無効化トピック（例: Kafka）にイベントが発行されます。キャッシュノードはこのトピックを購読し、対応するエントリを無効化/更新します。キャッシュエントリの短いTTL（例: 1〜5分）は、無期限の古い状態を防ぐためのフォールバックとして機能します。
  • 最終的な一貫性（分析）: 分析データは5分以内に最終的に整合性が取れます。これは、非同期メッセージキューとストリーム処理によって処理されます。これにより、分析の即時更新よりもリダイレクトパフォーマンスが優先されます。
• リージョン障害の処理:
  • グローバルロードバランシング/DNS: インテリジェントDNSサービス（例: GeoDNS）とグローバルロードバランサーは、リージョン障害を自動的に検出し、トラフィックを正常なアクティブリージョンにリダイレクトします。
  • データレプリケーション: 分散SQLデータベースは、全てのリックデータをアクティブリージョン全体にレプリケートします。あるリージョンが利用できなくなっても、他のリージョンはデータ損失やレイテンシへの影響を最小限に抑えながらリクエストを提供し続けることができます。
  • 段階的な機能低下: 分析サービスまたはメッセージキューに問題が発生した場合、リダイレクトサービスは、ローカルでのイベントバッファリング、または極端な場合にはイベントの破棄によって、コアリダイレクト機能を優先して機能を継続できるように設計されています。

5. 主要なトレードオフ、ボトルネック、リスク:

• 主要なトレードオフ:
  • 一貫性 vs. レイテンシ: リンク作成の強い一貫性（分散SQL経由）はデータ整合性を保証しますが、書き込みレイテンシがわずかに高くなる可能性があります。リダイレクトについては、最適化されたキャッシュによる最終的な一貫性が、80ミリ秒未満のレイテンシを実現するために選択されています。
  • キャッシュサイズ vs. コスト: 広範なキャッシュはリダイレクトパフォーマンスに不可欠ですが、かなりのメモリリソースが必要となり、インフラストラクチャコストが高くなります。キャッシュヒット率と運用コストのバランスを取る必要があります。
  • 短縮コードの長さ vs. 名前空間のサイズ: 短いコードはユーザーフレンドリーですが、衝突の可能性が高まり、ユニークなリンクの総数を制限します。7〜10文字のbase62コードは、広大で実用的な名前空間を提供します。
• ボトルネック:
  • 分散キャッシュ容量: キャッシュがピーク時の読み取りスループットを処理できない場合、またはアクティブなリンクのワーキングセットがメモリ容量を超える場合、リダイレクトはデータベースにフォールバックし、レイテンシとデータベース負荷が増加します。
  • データベース書き込みスループット: リンク作成の量はリダイレクトよりも少ないですが、1日あたり1億2000万件はかなりの量です。分散SQLデータベースは、ボトルネックになることなく、リージョン全体でこの書き込み負荷を処理できる必要があります。
  • リージョン間のネットワークレイテンシ: グローバルに分散されたシステムでのクロスリージョンデータレプリケーションと一貫性チェック、特に書き込み操作では、固有のレイテンシが発生する可能性があります。
• リスクと緩和策:
  • リスク1: 短縮コードの衝突（特にランダム生成の場合）:
    • 緩和策: 十分に長いshort_code（例: base62を使用した7〜10文字: a-z、A-Z、0-9）を使用します。堅牢な生成戦略を実装します: ユニークなコードの大きなプールを事前に生成する、分散IDジェネレーター（例: Snowflakeライク）を使用してユニークIDを生成してからbase62に変換する、またはカスタムエイリアスの場合は、楽観的ロックと再試行を使用してデータベースで直接一意性チェックを実行します。
  • リスク2: 有効期限切れ/削除済みリンクのキャッシュの陳腐化:
    • 緩和策: リアルタイムのキャッシュ無効化メカニズムを実装します。リンクのステータスが変更された場合（例: expires_atに到達、statusが'deleted'に設定）、短縮サービス（または専用のバックグラウンドジョブ）はKafkaトピックにイベントを発行します。全てのリダイレクトサービスインスタンスとキャッシュノードはこのトピックを購読し、対応するshort_codeエントリを直ちに無効化します。短いTTL（例: 1〜5分）はフォールバックとして機能します。
  • リスク3: short_codeの分布の不均一性によるデータベースのホットスポット:
    • 緩和策: 分散SQLデータベースの場合、内部のシャーディングとリバランス機能に依存します。カスタムエイリアスの場合は、エイリアス自体がプライマリキーとして機能し、うまく分散されるはずです。ランダムに生成された短縮コードの場合、シーケンシャルキーがホットスポットを引き起こすのを避けるために、生成アルゴリズムが十分にランダムなコードを生成することを確認します。データベースパーティションを監視し、必要に応じてリバランスします。

6. 容量見積もり:

• スループット:

  • リダイレクト: 1日あたり40億件 = 約46,300リクエスト/秒（平均）、ピーク時約138,900リクエスト/秒（平均の3倍）。
  • リンク作成: 1日あたり1億2000万件 = 約1,389リクエスト/秒（平均）、ピーク時約4,167リクエスト/秒（平均の3倍）。
  • 分析イベント取り込み: 約46,300イベント/秒（平均）、ピーク時約138,900イベント/秒。

• ストレージ:

  • リンクデータ（分散SQLデータベース）:
    • 平均レコードサイズ: 約100バイト（short_code、long_url、タイムスタンプ、ステータスなど）。
    • 1日あたりの新規リンク: 1億2000万件 * 100バイト = 12 GB。
    • 5年間での合計: 12 GB/日 * 365日/年 * 5年 = 約21.9 TB。
    • 高可用性/マルチリージョンのための3倍のレプリケーションファクターの場合: 約65.7 TB。
  • 分析データ（データウェアハウス）:
    • 平均イベントサイズ: 約100バイト（short_code、タイムスタンプ、国、デバイス、参照元）。
    • 1日あたりのイベント数: 40億件 * 100バイト = 400 GB。
    • 1年間の保持期間での合計: 400 GB/日 * 365日/年 = 約146 TB。
    • 3倍のレプリケーションファクターの場合: 約438 TB。
  • 分散キャッシュ（Redis Cluster）:
    • 各キャッシュエントリ: short_code（例: 10バイト）+ long_url（平均500バイト）= 約510バイト。
    • 10億件のアクティブリンク（人気のあるリンクの妥当なワーキングセット）をキャッシュする場合: 10億件リンク * 510バイト/リンク = 510 GBのキャッシュメモリ。これは、大規模でシャーディングされたRedis Clusterにとって、かなりのサイズですが管理可能です。

グローバルURL短縮サービス - システム設計

1. 高レベルアーキテクチャ

主要コンポーネント：

• API Gateway & Load Balancer: 北米、欧州、アジア向けのリージョナルルーティングを備えたグローバルなエントリーポイント
• Short Link Service: 作成、検証、エイリアス管理を担当
• Redirect Service: 最小限のレイテンシで高スループットなリダイレクト向けに最適化
• Cache Layer: 多層キャッシュ（エッジCDN、リージョナルRedis、ローカルインメモリ）
• Primary Data Store: リンクメタデータ用の分散SQLデータベース（シャーディングされたPostgreSQL）
• Analytics Pipeline: イベントストリーミング（Kafka）→ ストリームプロセッサ（Flink/Spark）→ 分析DB（ClickHouse/Druid）
• CDN: リダイレクトレスポンス向けのグローバルコンテンツ配信
• Message Queue: 非同期処理（有効期限切れ、削除、分析）用
• Monitoring & Observability: 分散トレーシング、メトリクス、アラート

リクエストフロー：

短縮リンク作成：

1. クライアント → API Gateway（リージョナル）
2. Short Link Service が入力を検証し、短縮コードを生成するか、カスタムエイリアスを検証
3. 分散キャッシュ + プライマリDBでエイリアスの一意性を確認
4. プライマリDBに書き込み（レプリケーション付き）
5. キャッシュを無効化し、イベントをKafkaに公開
6. 短縮リンクを返却（p95 < 300ms）

リダイレクト（読み取り）：

1. クライアント → 最寄りのCDNエッジロケーション
2. CDNがローカルキャッシュを確認し、ミスした場合はリージョナルキャッシュ（Redis）へルーティング
3. リージョナルキャッシュでミス → 読み取りレプリカ付きのプライマリDBに問い合わせ
4. レスポンスをCDNエッジとリージョナルRedisにキャッシュ
5. 301/302リダイレクトを返却（p95 < 80ms）
6. 非同期: クリックイベントをKafkaに公開

分析：

1. クリックイベント → Kafkaトピック
2. ストリームプロセッサが link_id、country、device、referrer ごとに集計
3. 集計済みメトリクスを1〜5分ごとに分析DBへ書き込み
4. ダッシュボードが分析DBにクエリしてレポートを取得

2. データモデルとストレージ選定

リンクメタデータテーブル（Primary DB - PostgreSQL）：

links:
  - link_id (UUID, primary key)
  - short_code (VARCHAR(10), unique index)
  - long_url (TEXT, max 500 bytes)
  - user_id (UUID, indexed)
  - custom_alias (VARCHAR(100), unique global index, nullable)
  - created_at (TIMESTAMP)
  - expires_at (TIMESTAMP, nullable, indexed)
  - is_deleted (BOOLEAN, indexed)
  - is_custom (BOOLEAN)
  - created_region (VARCHAR(10))
  - metadata (JSONB: title, description, tags)

分析イベントテーブル（時系列DB - ClickHouse）：

click_events:
  - event_id (UUID)
  - link_id (UUID, indexed)
  - timestamp (DateTime)
  - country (VARCHAR(2))
  - device_type (VARCHAR(20))
  - referrer_domain (VARCHAR(255))
  - user_agent (VARCHAR(500))
  - ip_hash (VARCHAR(64))

ストレージ選定の根拠：

• PostgreSQL（プライマリ）: リンク作成に対するACID保証、エイリアス一意性に対する強整合性、適切なシャーディングにより大規模運用で実績あり
• Redis（リージョナルキャッシュ）: ホットリンクに対してサブミリ秒のレイテンシ、自動期限切れのためのTTLをサポート、リージョン間に分散可能
• ClickHouse（分析）: 時系列分析に最適化、カラムナストレージにより保存容量を10〜100倍削減、高速集計が可能
• CDN（Cloudflare/Akamai）: グローバルエッジキャッシュによりレイテンシを p95 < 80ms に低減、オリジントラフィックをオフロード
• Kafka（イベントストリーム）: リダイレクト経路から分析を分離、リプレイ可能、複数コンシューマをサポート

3. 読み取り偏重トラフィック向けスケーリング戦略

キャッシュアーキテクチャ（多層）：

1. エッジCDNキャッシュ（Tier 1）:

   • リダイレクトレスポンスをグローバルにキャッシュ
   • TTL: アクティブなリンクは24時間、期限切れリンクは5分
   • キャッシュキー: short_code
   • ヒット率目標: 95%以上
   • オリジントラフィックを95%削減

2. リージョナルRedisクラスター（Tier 2）:

   • 3リージョン: us-east、eu-west、ap-southeast
   • 各リージョン: Redisクラスター6ノード（primary 3、replica 3）
   • アベイラビリティゾーンをまたぐレプリケーション
   • TTL: リンクは1時間、期限切れリンクは5分
   • 容量: 各リージョン500GB（ホットリンクのみ）

3. ローカルインメモリキャッシュ（Tier 3）:

   • サービスインスタンスごとのLRUキャッシュ（100MB）
   • 最もホットな上位1%のリンクについてRedis往復を削減

読み取りレプリカ戦略：

• プライマリDBは us-east（書き込みマスター）
• 読み取りレプリカは eu-west、ap-southeast に配置（非同期レプリケーション、約100msの遅延）
• 読み取りは最寄りのレプリカへルーティング
• レプリカが利用不可の場合はプライマリへフォールバック

水平スケーリング：

• Redirect Service: 各リージョンで1000以上のインスタンスまでオートスケール
• 各インスタンスは1日あたり約400万リダイレクトを処理（4B / 1000）
• ロードバランサーがレイテンシと容量に基づいて分散

短縮コード生成：

• 6文字コードに対するBase62エンコーディング（0-9, a-z, A-Z）
• 62^6 = 560億通りのコード（1日1.2億件でも400年以上十分）
• 衝突回避のため、リージョンプレフィックス付きの分散IDジェネレータ（Snowflake類似）
• バッチ割り当て: 各サービスインスタンスが事前に1万件のコードを確保

4. 信頼性戦略

フェイルオーバーと高可用性：

• マルチリージョンデプロイメント: 3リージョンでActive-Active構成
• データベースレプリケーション: 自動フェイルオーバー付きPostgreSQLストリーミングレプリケーション（Patroni）
• Circuit breakers: キャッシュ/DBが利用不可のときに障害の連鎖を防止
• Graceful degradation: 分析DBが停止してもリダイレクトは提供継続し、イベントはローカルにキューイング

整合性に関する判断：

• 書き込みは強整合性: リンク作成では、エイリアス一意性のために分散ロック（Redis/Zookeeper）を使用
• 読み取りは結果整合性: リダイレクトレスポンスが約100ms古い可能性がある（許容可能）
• 分析は結果整合性: 要件上、5分のウィンドウは許容可能
• 期限切れ処理: 遅延削除（読み取り時に expires_at を確認）+ バックグラウンドジョブ（毎時スキャン）

リージョン障害時の対応：

1. 障害検知: ヘルスチェックが30秒間失敗
2. フェイルオーバー: トラフィックを他リージョンへルーティング
3. 書き込み処理: プライマリリージョン（us-east）へリダイレクトし、フォールバックとしてローカルリージョンを使用
4. 読み取り処理: 他リージョンの読み取りレプリカを使用
5. 復旧: リージョン復旧時にプライマリからデータを同期
6. 監視: リージョン利用不可時にアラート、フェイルオーバーイベントを追跡

具体的な緩和策：

• データベース障害: Patroni によるレプリカへの自動フェイルオーバー（RTO < 30秒）
• キャッシュ障害: DBへバイパスしつつ、thundering herd を防ぐためにレート制限を適用
• CDN障害: トラフィックをリージョナルキャッシュへ直接ルーティング
• ネットワーク分断: 分断は回復すると仮定し、クォーラムベースの判断を使用
• データ破損: バックアップからのポイントインタイムリカバリ（日次スナップショット）

5. 主なトレードオフ、ボトルネック、リスク

トレードオフ：

1. 整合性 vs. レイテンシ: リダイレクトレイテンシを80ms未満に保つため、分析には結果整合性を採用。エイリアス一意性に対する強整合性は約50ms追加するが、正確性のために必要。

2. キャッシュTTL vs. 鮮度: 24時間のCDN TTLはオリジン負荷を減らす一方で、期限切れリンクが最大24時間リダイレクトされる可能性がある。削除済みとしてマークされたリンクには5分TTLを適用することで緩和。

3. ストレージ vs. クエリ速度: 高速集計を実現するため、分析データを非正規化（イベントテーブルに country、device を保持）し、2〜3倍の保存コスト増を受け入れる。

4. リージョン自律性 vs. グローバル整合性: 各リージョンは独立して読み取りを提供できるが、書き込みはエイリアス一意性のために協調が必要であり、レイテンシが増加する。

ボトルネック：

1. エイリアス一意性チェック: グローバルな分散ロックが必要で、書き込みピーク時の競合点になり得る。緩和策: Redis と Lua スクリプトで原子的な check-and-set を実装し、エイリアス先頭文字でシャーディング。

2. データベース書き込みスループット: 1日1.2億件の新規リンク = 約1,400書き込み/秒。PostgreSQL は1インスタンスあたり約1万書き込み/秒を処理できるため、1〜2台のプライマリインスタンスが必要。緩和策: バッチ書き込み、コネクションプーリング（PgBouncer）を使用。

3. 分析パイプライン: 1日40億クリック = 約4.6万イベント/秒。Kafka は処理可能だが、集計に遅延が出る可能性がある。緩和策: リアルタイム集計にストリームプロセッサ（Flink）を使い、1分ごとに分析DBへ書き込む。

3つの主要リスクと緩和策：

リスク1: 人気リンクの期限切れ時に発生するキャッシュスタンピード

• シナリオ: 1時間あたり100万クリックのバイラルリンクが期限切れとなり、すべてのキャッシュエントリが同時に無効化され、100万リクエストがDBに到達
• 影響: DB過負荷、リダイレクトレイテンシが秒単位まで急増、SLA違反
• 緩和策:
  • 確率的早期期限切れを使用: 実際の期限切れ5分前にキャッシュを更新
  • リクエスト集約を実装: 期限切れリンクに複数のリクエストが来ても、最初の1件だけがDBを問い合わせる
  • Circuit breaker でDBクエリレートの上限を設定し、超過時は404を返す
  • 期限切れが予想される既知リンクのキャッシュを事前ウォーム

リスク2: ネットワーク分断下での分散エイリアス衝突

• シナリオ: リージョン間でネットワーク分断が発生し、2人のユーザーが異なるリージョンで同じカスタムエイリアスを作成。分断回復後にデータ競合が発生
• 影響: エイリアス一意性が破られ、一方のリンクに到達できなくなる。データ不整合
• 緩和策:
  • エイリアス書き込みにはグローバル分散ロック（Zookeeper/etcd）を使用し、ロックが取得できない場合は失敗させる
  • 競合解決を実装: タイムスタンプベースで勝者を決定（より早い書き込みを優先）
  • 監査ジョブ: 重複エイリアスを毎日スキャンし、競合時にアラート
  • エイリアス書き込みはプライマリリージョン経由のみに制限（高レイテンシを受容）

リスク3: ストリーム処理障害中の分析データ損失

• シナリオ: Kafkaコンシューマがクラッシュし、イベントが処理されない。分析遅延が拡大し、メモリが埋まり、イベントがドロップされる
• 影響: クリック数が不正確になり、ビジネスメトリクスの信頼性が低下し、顧客信頼を損なう
• 緩和策:
  • オフセット管理付きKafkaコンシューマグループを使用し、最後にコミットしたオフセットから再開
  • 失敗イベント用のデッドレターキューを実装し、手動でリプレイ
  • ローカルイベントバッファにメモリ上限を設定し、満杯時は最古イベントをドロップ（アラート付き）
  • 分析の二重書き込み: Kafka → Stream processor と直接DB書き込みの両方を実施（重複排除付き）
  • コンシューマラグを監視し、ラグが5分を超えたらアラート

6. 容量見積もり

ストレージ：

リンクメタデータ（PostgreSQL）：

• 1日1.2億件の新規リンク × 365日 = 年間438億リンク
• 1リンクあたり: 50バイト（ID、タイムスタンプ、フラグ） + 500バイト（long URL） + 100バイト（metadata） = 650バイト
• 1年目: 438億 × 650B = 28.5TB
• 3年保持で: 85.5TB
• レプリケーション込み（3倍）: 256.5TB
• 10インスタンスにシャーディング: 1インスタンスあたり25.6TB（管理可能）

分析イベント（ClickHouse）：

• 1日40億クリック × 365日 = 年間1.46兆イベント
• 1イベントあたり: 50バイト（ID、タイムスタンプ） + 100バイト（country、device、referrer） = 150バイト
• 1年目: 1.46兆 × 150B = 219TB（非圧縮）
• ClickHouse圧縮: 10〜20倍 → 年間11〜22TB
• 3年保持: 33〜66TB（許容範囲）

キャッシュ（Redis）：

• ホットリンク（全体の1%）: 4.38億リンク
• キャッシュ内の1リンクあたり: 50バイト（short_code、long_urlポインタ） = 50バイト
• 4.38億 × 50B = リージョンあたり22GB
• 3リージョン: 合計66GB（各リージョン500GB割り当て内に収まる）

スループット：

書き込みスループット：

• 1.2億リンク/日 ÷ 86,400秒 = 1,389書き込み/秒
• PostgreSQL: 1つのプライマリインスタンスで1万書き込み/秒を処理 → 1インスタンスで十分
• Kafka: 1,389イベント/秒 → 1パーティションで十分（Kafka は1パーティションあたり10万超メッセージ/秒を処理可能）

読み取りスループット：

• 40億リダイレクト/日 ÷ 86,400秒 = 46,296読み取り/秒
• ピーク（3倍）: 138,888読み取り/秒
• CDNキャッシュヒット率: 95% → オリジンへの読み取りは6,944/秒
• Redisヒット率: ミスの99% → DBへの読み取りは70/秒
• PostgreSQL: 各リージョンの読み取りレプリカ1台で1万読み取り/秒を処理 → 各リージョン1レプリカで十分
• Redirect Service インスタンス: 46K読み取り/秒 ÷ 1インスタンスあたり100読み取り/秒 = 460インスタンス（ベースライン）、ピーク時1,389インスタンス

分析スループット：

• 1日40億クリック = 46,296イベント/秒
• Kafka: 1トピック、10パーティション（並列性）
• Stream processor: 10インスタンス、各4,630イベント/秒を処理
• ClickHouse: 1分ごとのバッチ挿入、46Kイベント/分 = 管理可能

ネットワーク帯域幅：

リダイレクトレスポンス：

• 46Kリダイレクト/秒 × 300バイト（HTTPレスポンス） = 13.8MB/秒
• ピーク時: 41.4MB/秒
• CDNが95%吸収 → ピーク時のオリジン向けは2.1MB/秒
• 1Gbps接続で十分に処理可能

分析イベント：

• 46Kイベント/秒 × 500バイト = 23MB/秒
• Kafkaクラスター: 10Gbps容量 → 十分

要約表：

| コンポーネント | 容量 | インスタンス数 | 備考 |
|-----------|----------|-----------|-------|
| PostgreSQL Primary | 10K書き込み/秒 | 1 | 将来の成長に備えてシャーディング |
| PostgreSQL Read Replicas | 10K読み取り/秒 | 3（各リージョンに1） | 非同期レプリケーション |
| Redis Clusters | 100K ops/秒 | 3（各リージョンに1） | 各6ノード |
| Redirect Service | 100リダイレクト/秒 | 460（ベースライン）、1,389（ピーク） | オートスケーリング |
| Kafka Brokers | 100K msgs/秒 | 3 | レプリケーション係数3 |
| Stream Processors | 4,630イベント/秒 | 10 | Flink/Spark |
| ClickHouse Nodes | 1M inserts/秒 | 3 | 分散クラスター |
| CDN Edge Locations | グローバル | 200+ | Cloudflare/Akamai |

実装の優先順位

1. Phase 1（MVP）: 単一リージョン、PostgreSQL + Redis + CDN、基本分析
2. Phase 2（スケール）: マルチリージョン、読み取りレプリカ、Kafka分析パイプライン
3. Phase 3（最適化）: 分散ID生成、高度なキャッシュ、ClickHouse分析
4. Phase 4（堅牢化）: Circuit breakers、カオスエンジニアリング、災害復旧訓練