ニュースフィード／タイムラインの設計

要件と規模の見積もり

機能要件は、フォロー関係に基づく逆時系列（またはランク付き）タイムラインの取得、投稿の作成、フィードへの反映です。非機能要件は、読み取りの低レイテンシ（p99 で数百ms以内）、高可用性、結果整合で許容（投稿が数秒遅れて現れてよい）、読み取りが書き込みを圧倒的に上回る点です。

フェルミ推定を置きます。月間アクティブ 5億、日次アクティブ（DAU）2億と仮定します。1人が1日2回投稿なら書き込みは 4億/日、平均 4億 / 86,400 ≒ 4,600 投稿/秒、ピークはその約3倍で 1.4万 QPS。読み取りは1人が1日10回フィードを開くとして 20億/日 ≒ 2.3万 QPS、ピーク 7万 QPS。読み書き比はおよそ 5:1 で、読み取り最適化が設計の主軸になります。

ストレージは、投稿1件のメタデータ（ID・著者・本文・タイムスタンプ）を約 300 バイトとすると 4億 × 300B ≒ 120GB/日、年間で約 44TB。メディア本体は別途オブジェクトストレージ＋CDNに逃がし、フィード経路にはIDと軽量メタだけを流します。

大枠の設計

APIは薄いRESTで十分です。カーソルベースのページングにするのは、オフセットpage番号だと新規投稿の挿入でズレるためです。

POST /v1/posts                 body: {text, mediaIds}
GET  /v1/feed?cursor=<opaque>&limit=20   -> {items, nextCursor}
POST /v1/follow                body: {targetUserId}

データモデルは3系統に分けます。関係DB（またはグラフ）に users と follows(follower_id, followee_id)、投稿の正となる posts を保持し、フィード配信用に Redis の受信箱を別途持ちます。受信箱はユーザーごとの List か時刻でソートした Sorted Set で、値は本文ではなくポストIDに限定します。

主要コンポーネントの深掘り

配信の中心は fan-out サービスです。投稿を受けると著者のフォロワー一覧を引き、各受信箱の Sorted Set へポストIDを ZADD します。この書き込みは同期にせず、メッセージキュー越しに非同期ワーカーで処理します。理由は、投稿APIの応答を受信箱書き込みの完了から切り離し、ピーク時の書き込みをキューで平滑化するためです（配信保証の設計はメッセージキューの配送セマンティクスを参照）。

読み取り時はまず受信箱のポストID列を取り、本文は別のポストキャッシュから一括取得（マルチゲット）して合成します。ここでの分割は、ID列（順序）と本文（内容）を別ライフサイクルで扱うためで、本文はイミュータブルなので積極的にキャッシュできます。

ランキングは純粋な逆時系列を基点に、スコア関数へ切り替えます。素朴には score = w1*親密度 + w2*エンゲージメント予測 + w3*鮮度減衰 の形で、鮮度は経過時間の指数減衰にします。エッジ重み（EdgeRank 系）の考え方で、誰の投稿を優先するかを親密度で調整します。

ボトルネックとトレードオフ

横にスクロール

最大の壁は書き込み増幅です。フォロワー数はべき乗則（ロングテール）に従い、中央値は数十でも上位は数千万に達します。プッシュ一択だと、フォロワー3,000万の1投稿が3,000万回の受信箱書き込みへ増幅し、キューとRedisを飽和させます。だからハイブリッドで、フォロワーが閾値（例 100万）を超える著者だけをプルに回し、読み取り時にその数十人分をオンザフライでマージします。閾値は「増幅コスト」と「読み取り時マージコスト」が釣り合う点に置きます。

もう一つは受信箱の肥大です。全ユーザーの全受信箱を無限に持つのは非現実的なので、上限件数（例 直近800件）でトリム（ZREMRANGEBYRANK）し、それ以前はプルで正の posts から辿ります。休眠ユーザーには受信箱を事前生成せず、初回アクセス時に遅延生成することで無駄な fan-out を消せます。

スケール時は、フォロー関係DBのシャーディング戦略（ユーザーIDでのハッシュ分割）、Redisクラスタの水平分割、地理レプリカでの読み取り局所化が効きます。トレードオフは常に整合性で、受信箱・キャッシュ・ランキングの各層で「どれだけ古い結果を許すか」を明示的に決めることが、この規模を成立させる前提になります。ストレージ層の分散設計はデータベーストピックも参照してください。