バズった投稿のリアルタイムなビュー / いいねカウンターをどう構築しますか？

Question

IT Interview Practice · Accepted Answer

ホットな投稿に対してイベントごとに `UPDATE posts SET views = views + 1` を実行してはいけません。その1行がロックのボトルネックになります。**Redisでインクリメントし、数秒ごとにDBへバッチフラッシュ**し、カウントはRedisから読み取ります。DBはライブトラフィックではなく永続的な合計を保存します。

## アーキテクチャ

```text
Client tap ─▶ API ─▶ Redis INCR views:{post}   (live, source of truth for reads)
                          │            └── dedup: SADD seen:{post} {user/ip}
                          ▼
                 every ~5s / N ops
              Flusher ─▶ UPDATE posts SET views = views + delta   (durable)
                          ▲
                 read path: GET Redis (fallback DB on miss)
```

## コンポーネントと処理の流れ

- **Redis INCR** が書き込みの嵐を吸収します。単一の `INCR views:{post}` はアトミックで、1つのキーで10万以上のops/sを処理します。Postgresの行より桁違いです。このカウンターは*読み取り*の真実の源なので、閲覧者は数字が即座に動くのを見ます。
- **いいね / ユニークビューのdedup**：生のカウンターはリロードを二重カウントします。`SADD seen:{post} {userId}` を使い、追加が新規のときだけ `INCR` します。大規模での安価な近似ユニーク数には**HyperLogLog**（`PFADD`/`PFCOUNT`）を使います。数KBで数百万のユニーク数を約2%の誤差内で推定します。
- **バッチ化されたflusher**が定期的にデルタをDBへ流します：`UPDATE posts SET views = views + delta`。5秒ごとまたはNインクリメントごとにフラッシュすることで、100万の書き込みをわずか数回に変えます。DBはコールドな投稿と分析のための永続的合計を保持します。
- **読み取りパス**はRedisから提供します。キャッシュミス時にはDBの合計を読み、Redisを再ウォームアップします。いいねはユーザーごとの状態（*自分*がいいねしたか）が必要なので、単なる数字ではなくセットを保存します。

## 面接での観点

面接官は、あなたが**カウントの結果整合性を受け入れる**かをテストします。「良い」回答は「カウントをキャッシュする」ですが、「優れた」回答は*書き込み*をバッファリングすること、つまりボトルネックが読み取り負荷ではなくホット行への書き込み競合だと認識することです。彼らはトレードを探ります。近似カウントは許容できるか？ビュー数についてはイエスです。1,203,428と1,203,450の違いに誰も気づきません。罠は、正確なカウントを気にしてトランザクションに手を伸ばし、避けていたロックを再導入することです。

## トレードオフと障害

- **正確性対スループット**：正確なカウントにはdedupセット（メモリを消費）が必要です。近似HyperLogLogは小さく高速です。機能ごとに選びます。いいねは正確に、ビュー数は近似で構いません。
- **耐久性**：Redisはインメモリです。フラッシュ前に落ちると、未フラッシュのデルタを失います。AOFを有効にし、フラッシュ間隔を短く（秒単位）保って損失を制限します。DBの合計に小さなギャップがあるのはビューカウンターでは許容範囲です。
- **ホットキー**：バズった投稿はすべてのトラフィックを1つのRedisキーに集中させます。`views:{post}:{0..9}` にシャーディングして読み取り時に合計するか、ホットキーを専用ノードにルーティングして、1つの投稿がシャードを飽和させないようにします。

アーキテクチャ

コンポーネントと処理の流れ

面接での観点

トレードオフと障害

関連する質問