Kepiye carane sampeyan mbangun counter view/like real-time kanggo postingan viral?

Question

IT Interview Practice · Accepted Answer

Aja tau nglakoni `UPDATE posts SET views = views + 1` saben event ing postingan sing panas — siji row kuwi dadi bottleneck kunci. **Increment ing Redis, batch-flush menyang DB** saben pirang-pirang detik, lan waca cacahe saka Redis. DB nyimpen total sing tahan lama, dudu lalu lintas 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 lan aliran

- **Redis INCR** nyerap badai tulisan. Siji `INCR views:{post}` iku atomik lan nangani 100rb+ ops/s ing siji key — sepira-pira orde luwih akeh tinimbang row Postgres. Counter iki minangka sumber kebeneran kanggo *pamaca*, mula sing ndeleng bakal weruh angkane obah sanalika.
- **Dedup kanggo like/unique view**: counter mentahan bakal ngetung refresh kaping pindho. Nganggo `SADD seen:{post} {userId}` lan mung `INCR` yen tambahane anyar; kanggo perkiraan unik sing murah ing skala gedhe nganggo **HyperLogLog** (`PFADD`/`PFCOUNT`) — mung sawetara KB kanggo ngira-ira jutaan unik ing kesalahan ~2%.
- **Batched flusher** kanthi periodik mili delta menyang DB: `UPDATE posts SET views = views + delta`. Flush saben 5 detik utawa saben N increment ngowahi sejuta tulisan dadi sethithik wae — DB nyekel total sing tahan lama kanggo postingan adhem lan analitik.
- **Read path** ngladeni saka Redis; nalika cache miss iku maca total DB lan manasi maneh Redis. Like mbutuhake state saben pangguna (apa *aku* wis like), mula simpen set-e, dudu mung angka.

## Sudut pandang wawancara

Pewawancara nguji apa sampeyan nampa **eventual consistency kanggo cacahan**. "Apik" yaiku "cache cacahe"; "apik banget" yaiku nge-buffer *tulisan* — ngerteni yen bottleneck-e yaiku contention tulisan ing row panas, dudu beban maca. Dheweke nyoba trade-e: apa cacahan perkiraan bisa ditampa? Kanggo cacahan view, bisa — ora ana sing nggatekake 1.203.428 vs 1.203.450. Jebakane yaiku kuwatir babagan cacahan sing pas lan njangkau transaksi, sing malah nglebokake maneh lock sing arep sampeyan hindari.

## Trade-off lan kegagalan

- **Akurasi vs throughput**: cacahan sing pas mbutuhake dedup set (akeh memori); HyperLogLog perkiraan iku cilik lan cepet. Pilih saben fitur — like iku pas, cacahan view bisa perkiraan.
- **Durabilitas**: Redis iku ing memori. Yen mati sadurunge flush, sampeyan ilang delta sing durung di-flush. Aktifake AOF lan gawe jendhela flush cendhak (detik) kanggo mbatesi kerugian; total DB tambah gap cilik bisa ditampa kanggo counter view.
- **Hot key**: postingan viral nglumpukake kabeh lalu lintas ing siji key Redis. Bagi dadi `views:{post}:{0..9}` lan jumlahake nalika maca, utawa arahake hot key menyang node khusus supaya siji postingan ora bisa nyenyeti shard.

Arsitektur

Komponen lan aliran

Sudut pandang wawancara

Trade-off lan kegagalan

Pitakon sing gegandhengan