規模見積もり:

• 書き込みQPS: 500,000 / 86,400 = ~6 QPS
• 読み取りQPS（読み書き比率5
  ）: ~30 QPS
• 1ペーストの平均サイズ: 10KB
• 1日のストレージ: 500,000 * 10KB = 5GB/日

アーキテクチャ:

クライアント → LB → Webサーバー → メタデータDB (RDB)
                                  → コンテンツストレージ (S3)
                                  → キャッシュ (Redis)

URL生成: Base62エンコーディング + Snowflake ID。短いテキストはメタデータDBに、長いテキストはS3に保存。期限切れペーストはバッチジョブで定期削除。

画像アップロードフロー:

1. クライアントがAPIサーバーに署名付きURLを要求
2. クライアントがS3に直接アップロード（サーバー負荷回避）
3. S3イベントがLambdaをトリガー → リサイズ（サムネイル/中/大）
4. メタデータをDBに保存、フォロワーにFan-out

フィード戦略: ハイブリッド方式。フォロワー10,000未満はPush、以上はPull。Redis Sorted Setでフィードキャッシュ管理。

CDN: CloudFront/Fastlyで画像を配信。WebPフォーマットで容量30%削減。

ストレージ: 1画像平均500KB x 3サイズ = 1.5MB。5000万DAU x 0.5投稿/日 = 37.5TB/日。

位置情報管理: ドライバーは4秒ごとに位置情報を送信。Redis GeoSetで管理（GEOADD/GEORADIUS）。

近接検索:

// Redis GeoSetで半径5km以内のドライバーを検索
const nearbyDrivers = await redis.georadius(
  'drivers:active', longitude, latitude, 5, 'km', 'WITHCOORD', 'COUNT', 20
);

マッチングフロー:

1. 乗客がリクエスト送信
2. 半径内のドライバーを検索（GeoSet）
3. ETA、評価、受付率でスコアリング
4. 上位ドライバーに順番にリクエスト送信（15秒タイムアウト）
5. 受諾されたらマッチング成立

ETA計算: Google Maps API + 過去データの機械学習モデルで補正。

同期プロトコル: WebSocketで双方向通信。各操作をOperation（挿入/削除/書式変更）として送受信。

競合解決:

• OT（Operational Transformation）: サーバーが操作を変換して適用順序を調整。Google Docsで使用。
• CRDT（Conflict-free Replicated Data Type）: データ構造自体が競合を解決。Figma等で使用。
• 推奨: OTの方が実装事例が多く、テキスト編集に適している。

永続化: 操作はイベントログとして保存。定期的にスナップショットを取得（5分間隔）。ドキュメント取得時は最新スナップショット + 以降の操作を適用。

カーソル共有: WebSocket経由でカーソル位置と選択範囲をブロードキャスト。色でユーザーを区別。