Kako izgraditi real-time brojač pregleda/lajkova za viralne objave?

Question

IT Interview Practice · Accepted Answer

Nikada ne radite `UPDATE posts SET views = views + 1` po događaju na vrućoj objavi — taj jedan redak postaje usko grlo zaključavanja. **Inkrementirajte u Redisu, batch-flush u bazu** svakih nekoliko sekundi i čitajte broj iz Redisa. Baza pohranjuje trajne ukupne vrijednosti, a ne živi promet.

## Arhitektura

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

## Komponente i tok

- **Redis INCR** apsorbira oluju upisa. Jedan `INCR views:{post}` je atomski i obrađuje 100k+ operacija/s na jednom ključu — nekoliko redova veličine iznad Postgres retka. Ovaj brojač je izvor istine za *čitanja*, pa gledatelji vide da se broj mijenja trenutno.
- **Dedup za lajkove/jedinstvene preglede**: sirovi brojač dvostruko broji osvježavanja stranice. Koristite `SADD seen:{post} {userId}` i `INCR` samo kada je dodavanje novo; za jeftine približne jedinstvene vrijednosti na velikoj skali koristite **HyperLogLog** (`PFADD`/`PFCOUNT`) — nekoliko KB procjenjuje milijune jedinstvenih uz ~2% pogreške.
- **Batch flusher** povremeno prazni deltu u bazu: `UPDATE posts SET views = views + delta`. Prazneći svakih 5 s ili svakih N inkrementa pretvara milijun upisa u nekoliko — baza drži trajni ukupni broj za hladne objave i analitiku.
- **Put čitanja** poslužuje iz Redisa; pri cache missu čita ukupni broj iz baze i ponovno zagrijava Redis. Lajkovi trebaju stanje po korisniku (jesam li *ja* lajkao), pa pohranite skup, a ne samo broj.

## Perspektiva intervjua

Ispitivači testiraju prihvaćate li **eventual consistency za brojače**. "Dobro" je "cachiraj broj"; "odlično" je bufferiranje *upisa* — prepoznavanje da je usko grlo borba za upis na vrući redak, a ne opterećenje čitanjem. Ispituju kompromis: je li približan broj prihvatljiv? Za broj pregleda, da — nitko ne primjećuje 1.203.428 vs 1.203.450. Zamka je brinuti o točnom broju i posegnuti za transakcijom, ponovno uvodeći zaključavanje koje ste izbjegavali.

## Kompromisi i neuspjesi

- **Točnost vs throughput**: točni brojevi trebaju dedup skupove (memorijski zahtjevni); približni HyperLogLog je sićušan i brz. Odaberite po značajci — lajkovi su točni, broj pregleda može biti približan.
- **Trajnost**: Redis je in-memory. Ako padne prije flusha, gubite neispraznjenu deltu. Uključite AOF i držite flush prozore kratkima (sekunde) da ograničite gubitak; DB ukupno plus mali jaz je prihvatljivo za brojač pregleda.
- **Vrući ključ**: viralna objava koncentrira sav promet na jedan Redis ključ. Shardirajte ga na `views:{post}:{0..9}` i zbrojite pri čitanju, ili usmjerite vruće ključeve na namjenski čvor kako jedna objava ne bi zasitila shard.

Arhitektura

Komponente i tok

Perspektiva intervjua

Kompromisi i neuspjesi

Povezana pitanja