[0〜5分]   要件収集とスコープ定義
[5〜10分]  キャパシティ推定（Back-of-envelope calculation）
[10〜20分] 高レベル設計（アーキテクチャ図）
[20〜35分] 主要コンポーネントの詳細設計
[35〜43分] トレードオフ議論と改善案の提示
[43〜45分] 面接官からの質問への対応

垂直:   [Server 4GB RAM] → [Server 32GB RAM]
水平:   [Server] + [Server] + [Server] → ロードバランサーの前に配置

ユーザー → [最寄りCDNエッジ] → (キャッシュヒット) → コンテンツ返却
                             → (キャッシュミス) → [オリジンサーバー] → CDNキャッシュ後返却

1. アプリがキャッシュからデータを照会
2. キャッシュミス → DBから照会
3. DB結果をキャッシュに保存
4. 以降のリクエストはキャッシュヒット

1. アプリがキャッシュに書き込み
2. キャッシュが同期的にDBにも書き込み
→ データ整合性を保証、書き込み遅延が発生

1. アプリがキャッシュのみに書き込み
2. キャッシュが非同期的にDBに書き込み
→ 書き込み性能が優秀、キャッシュ障害時にデータ損失リスク

実務ではネットワーク分断（P）は避けられないため
  CPシステム：銀行、株式取引（整合性優先）
  APシステム：SNSフィード、ショッピングカート（可用性優先）

リング構造（0 〜 2^32 - 1）：

        0
       /|\
      / | \
Server A  Server B
    \   |   /
     Server C

キーは時計回りに最も近いサーバーに割り当て
サーバー削除時はそのサーバーのキーのみが次のサーバーへ移動

Producer → [Message Queue] → Consumer

メリット：
- 非同期処理でレスポンス時間を短縮
- トラフィックバッファリング（トラフィックスパイクを吸収）
- サービス間の結合度を低減

書き込みQPS：
  - 1日の新規URL生成数：100M / 100 = 1M件/日
  - 書き込みQPS：1,000,000 / 86,400 ≈ 12 QPS

読み取りQPS：
  - 読み取り = 書き込み × 100 = 1,200 QPS
  - ピーク：1,200 × 5 = 6,000 QPS

ストレージ：
  - URLレコード1件 ≈ 500バイト
  - 10年分のデータ：1M × 365 × 10 × 500バイト ≈ 1.8 TB

キャッシュ：
  - 80/20の法則：上位20%のURLが80%のトラフィックを生成
  - キャッシュサイズ：1,200 QPS × 86,400 × 0.2 × 500バイト ≈ 10 GB/日

POST /api/v1/urls
  リクエスト：{ "long_url": "https://example.com/...", "expire_date": "2027-01-01" }
  レスポンス：{ "short_url": "https://tinyurl.com/abc123" }

GET /{short_code}
  レスポンス：301リダイレクト（永続）または302リダイレクト（一時）
  → 301：ブラウザがキャッシュ → サーバー負荷軽減（分析不可）
  → 302：常にサーバー経由 → クリック分析が可能

文字セット：[0-9, a-z, A-Z] = 62文字
6桁のBase62 = 62^6 = 568億通り

long_url → MD5/SHA-256 → 最初の7バイトを抽出 → Base62エンコード → 短縮コード

例：
  "https://www.example.com/long-path"
  → MD5: "1a2b3c4d..."
  → 最初の7バイトの整数値 → Base62 → "aB3xY9z"

CREATE TABLE url_mappings (
  id          BIGINT PRIMARY KEY,        -- Snowflake ID
  short_code  VARCHAR(8) UNIQUE NOT NULL,
  long_url    TEXT NOT NULL,
  user_id     BIGINT,
  created_at  TIMESTAMP DEFAULT NOW(),
  expire_at   TIMESTAMP,
  click_count BIGINT DEFAULT 0
);

CREATE INDEX idx_short_code ON url_mappings(short_code);

[クライアント]
     |
     v
[DNS] → [CDN]（静的リソース）
     |
     v
[ロードバランサー]
     |
     +-----------+-----------+
     v           v           v
[APIサーバー] [APIサーバー] [APIサーバー]
     |               |
     v               v
[Redisキャッシュ]  [URL DB（マスター）]
（短縮URLキャッシュ）    |
                [URL DB（レプリカ）]
                （読み取り専用）

書き込みフロー：
  クライアント → LB → APIサーバー → DB保存 → Redisキャッシュ更新 → 短縮URL返却

読み取りフロー：
  クライアント → LB → APIサーバー → Redisキャッシュ確認
    → キャッシュヒット：即座にリダイレクト
    → キャッシュミス：DB照会 → Redis保存 → リダイレクト

ツイート作成時：
  1. ツイートをDBに保存
  2. 作成者の全フォロワーIDを取得
  3. 各フォロワーのタイムラインキャッシュ（Redis）にツイートIDを挿入

メリット：読み取りが非常に速い（Redisから直接取得）
デメリット：1億フォロワー = 1億回の書き込み → 書き込み遅延が大きい

タイムライン取得時：
  1. フォロー中アカウントのリストを取得
  2. 各アカウントの最新ツイートを取得してマージ
  3. 時系列でソートして返却

メリット：書き込みがシンプル
デメリット：読み取り時にフォロー数分のDBクエリ → 読み取り遅延が大きい

一般ユーザー（フォロワー < 10,000）：Fan-out on write
セレブユーザー（フォロワー >= 10,000）：Fan-out on read

タイムライン生成：
  1. Redisから一般ユーザーのツイートIDを取得（Fan-out on write結果）
  2. フォロー中セレブの最新ツイートを取得（Fan-out on read）
  3. 両結果をマージしてソート

キー：timeline:{user_id}
値：Sorted Set（スコア = ツイートのタイムスタンプ、メンバー = tweet_id）

例：
  ZADD timeline:123 1700000001 tweet:456
  ZADD timeline:123 1700000002 tweet:789
  ZREVRANGE timeline:123 0 19  # 最新20件取得

最大1,000件のツイートIDのみ保持（メモリ管理）

64ビット構造：
  [1ビット：符号] [41ビット：タイムスタンプ] [10ビット：マシンID] [12ビット：シーケンス]

メリット：
  - 時系列ソートが可能（タイムスタンプ内包）
  - 分散環境で重複なし
  - 1秒あたり4,096個 × マシン数分の生成が可能

[モバイル/Webクライアント]
         |
    [APIゲートウェイ]
         |
   +-----------+
   |           |
[ツイートサービス] [タイムラインサービス]
   |                |
[ツイートDB]  [Redisタイムラインキャッシュ]
(Cassandra)          |
                [Fan-outサービス]
                （Kafkaを消費して
                 フォロワーのタイムラインを更新）
                     |
              [フォロワーグラフDB]
              （フォロー関係を保存）

メディア処理：
[画像/動画アップロード] → [オブジェクトストレージ（S3）] → [CDN]

[ユーザー]
   |
   v
[アップロードサービス] → S3にオリジナル保存
   |
   v
[メッセージキュー（Kafka）]
   |
   v
[トランスコーディングワーカー]（並列処理）
   ├── 360p変換
   ├── 720p変換
   ├── 1080p変換
   └── 4K変換
   |
   v
[CDNへ配信]
   |
   v
[メタデータDB更新] → ユーザーへ完了通知

ユーザーのネットワーク状態に応じて自動的に画質切り替え：

[良好なネットワーク]   → 1080p/4Kセグメントをリクエスト
[普通のネットワーク]   → 720pセグメントをリクエスト
[低品質なネットワーク] → 360pセグメントをリクエスト

HLS（HTTP Live Streaming）方式：
  - 動画を2〜10秒のセグメント（.tsファイル）に分割
  - M3U8プレイリストファイルでセグメントリストを管理
  - クライアントがバッファ状態を定期確認して画質を決定

[オリジンサーバー] → [リージョナルCDN] → [エッジCDN] → [ユーザー]

人気動画：複数のエッジノードに事前キャッシュ（Push CDN）
非人気動画：初回リクエスト時にオリジンから取得してキャッシュ（Pull CDN）

Netflixの場合：ISPと直接協力してISP内部にキャッシュサーバーを配置
              （OCA：Open Connect Appliance）

アップロード経路：
[クリエイター] → [アップロードAPI] → [S3] → [Kafka] → [トランスコーディングクラスター]
                                                          |
                                                    [CDN配信]

視聴経路：
[ユーザー] → [APIゲートウェイ] → [動画サービス]
                                       |
                         +-------------+-------------+
                         |             |             |
                    [メタデータ]  [CDNストリーム]  [推薦エンジン]
                    (MySQL)      (HLS/DASH)   (MLモデル)

クライアント ←→ WebSocket接続 ←→ チャットサーバー
  （継続的な双方向通信）

Cassandraスキーマ：
  パーティションキー：channel_id
  クラスタリングキー：message_id（Snowflake、時系列ソート）

  CREATE TABLE messages (
    channel_id  UUID,
    message_id  BIGINT,      -- Snowflake ID（時刻内包）
    sender_id   UUID,
    content     TEXT,
    created_at  TIMESTAMP,
    PRIMARY KEY (channel_id, message_id)
  ) WITH CLUSTERING ORDER BY (message_id DESC);

→ チャンネルごとの最新メッセージ取得が非常に効率的
→ 水平スケーリングが容易

メッセージの状態：SENT → DELIVERED → READ

1. メッセージ送信 → 状態SENTでDBに保存
2. 受信者の端末に到達 → DELIVEREDに更新 → 送信者へ通知
3. 受信者がメッセージを確認 → READに更新 → 送信者へ通知

方法1：ハートビート（30秒ごとにサーバーへpingを送信）
  - Redisに user:{id}:last_seen = タイムスタンプ を保存
  - TTL 60秒設定 → 60秒以上pingがなければオフライン

方法2：WebSocket接続状態の追跡
  - 接続時にオンライン、切断時にオフラインイベントを発生
  - 友達へPub/Subで状態変更を伝播

小規模グループ（N < 100）：
  [送信者] → [チャットサーバー] → [各メンバーに直接WebSocket送信]

大規模グループ（N >= 100）：
  [送信者] → [チャットサーバー] → [Kafkaトピック：group:{id}]
                                         |
                                   [コンシューマークラスター]
                                         |
                              [各メンバーの端末へプッシュ通知]

WhatsAppのSignalプロトコルベース：
  1. 各端末で公開鍵・秘密鍵のペアを生成
  2. サーバーには公開鍵のみを登録
  3. 送信者：受信者の公開鍵でメッセージを暗号化
  4. サーバー：暗号化済みメッセージのみを中継（内容を解読不可）
  5. 受信者：自身の秘密鍵で復号化

読み取りスケーリング：マスター・スレーブレプリケーション + 読み取り専用レプリカ
書き込みスケーリング：シャーディング（Consistent Hashing）
キャッシング：Redis（インメモリ） → DB負荷を削減
検索：Elasticsearch → 全文検索
時系列データ：InfluxDB / TimescaleDB
グラフデータ：Neo4j / Amazon Neptune

タスクキュー：重い処理（トランスコーディング、メール送信）を非同期処理
イベントストリーミング：Kafka → サービス間のイベント伝播
CQRS：読み取り/書き込みモデルを分離してパフォーマンスを最適化
Sagaパターン：分散トランザクションの処理