Bagaimana Anda membangun counter view/like real-time untuk postingan viral?

Question

IT Interview Practice · Accepted Answer

Jangan pernah `UPDATE posts SET views = views + 1` per event pada postingan panas — satu baris itu menjadi bottleneck lock. **Increment di Redis, lakukan batch-flush ke DB** setiap beberapa detik, dan baca jumlahnya dari Redis. DB menyimpan total yang durable, bukan trafik langsung.

## Arsitektur

```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)
```

## Komponen dan alur

- **Redis INCR** menyerap badai write. Sebuah `INCR views:{post}` tunggal bersifat atomik dan menangani 100k+ ops/s pada satu key — beberapa orde besar melampaui satu baris Postgres. Counter ini adalah sumber kebenaran untuk *pembacaan*, sehingga penonton melihat angka bergerak seketika.
- **Dedup untuk like/unique view**: counter mentah menghitung ganda saat refresh. Gunakan `SADD seen:{post} {userId}` dan hanya `INCR` ketika penambahan itu baru; untuk unique perkiraan yang murah pada skala masif gunakan **HyperLogLog** (`PFADD`/`PFCOUNT`) — beberapa KB memperkirakan jutaan unique dalam galat ~2%.
- **Flusher berbatch** secara berkala menguras delta ke DB: `UPDATE posts SET views = views + delta`. Mem-flush setiap 5 detik atau setiap N increment mengubah sejuta write menjadi segelintir — DB menyimpan total durable untuk postingan dingin dan analitik.
- **Read path** melayani dari Redis; saat cache miss ia membaca total DB dan menghangatkan ulang Redis. Like memerlukan state per-pengguna (apakah *saya* menyukainya), jadi simpan set-nya, bukan sekadar angka.

## Perspektif wawancara

Pewawancara menguji apakah Anda menerima **eventual consistency untuk counter**. "Baik" adalah "cache jumlahnya"; "hebat" adalah mem-buffer *write* — menyadari bottleneck adalah kontensi write pada satu baris panas, bukan beban baca. Mereka menyelidiki trade-off: apakah jumlah perkiraan bisa diterima? Untuk view count, ya — tidak ada yang memperhatikan 1.203.428 vs 1.203.450. Jebakannya adalah mengkhawatirkan jumlah eksak dan meraih transaksi, memunculkan kembali lock yang sedang Anda hindari.

## Trade-off dan kegagalan

- **Akurasi vs throughput**: jumlah eksak butuh dedup set (berat memori); HyperLogLog perkiraan sangat kecil dan cepat. Pilih per fitur — like eksak, view count bisa perkiraan.
- **Durability**: Redis in-memory. Jika mati sebelum flush, Anda kehilangan delta yang belum ter-flush. Aktifkan AOF dan jaga jendela flush tetap pendek (detik) untuk membatasi kerugian; total DB plus celah kecil dapat diterima untuk view counter.
- **Hot key**: postingan viral memusatkan seluruh trafik pada satu Redis key. Shard menjadi `views:{post}:{0..9}` dan jumlahkan saat baca, atau arahkan hot key ke node khusus agar satu postingan tidak menjenuhkan shard.

Arsitektur

Komponen dan alur

Perspektif wawancara

Trade-off dan kegagalan

Pertanyaan terkait