Cum construiești un contor de vizualizări/aprecieri în timp real pentru postări virale?

Question

IT Interview Practice · Accepted Answer

Nu face niciodată `UPDATE posts SET views = views + 1` per eveniment pe o postare fierbinte — acel singur rând devine un blocaj de lock. **Incrementează în Redis, golește în batch către DB** la fiecare câteva secunde și citește numărul din Redis. DB-ul stochează totalurile durabile, nu traficul live.

## Arhitectură

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

## Componente și flux

- **Redis INCR** absoarbe furtuna de scrieri. Un singur `INCR views:{post}` este atomic și gestionează 100k+ operații/s pe o cheie — cu ordine de mărime peste un rând de Postgres. Acest contor este sursa de adevăr pentru *citiri*, așa că vizitatorii văd numărul mișcându-se instantaneu.
- **Dedup pentru aprecieri/vizualizări unice**: un contor brut numără de două ori refresh-urile. Folosește `SADD seen:{post} {userId}` și fă `INCR` doar când adăugarea este nouă; pentru unici aproximativi ieftini la scară masivă folosește **HyperLogLog** (`PFADD`/`PFCOUNT`) — câțiva KB estimează milioane de unici cu ~2% eroare.
- **Flusher-ul în batch** golește periodic delta către DB: `UPDATE posts SET views = views + delta`. Golirea la fiecare 5s sau la fiecare N incrementări transformă un milion de scrieri într-o mână de scrieri — DB-ul deține totalul durabil pentru postările reci și pentru analytics.
- **Calea de citire** servește din Redis; la un cache miss citește totalul din DB și re-încălzește Redis. Aprecierile necesită stare per utilizator (am apreciat *eu*?), deci stochează setul, nu doar un număr.

## Perspectiva de interviu

Intervievatorii testează dacă accepți **consistența eventuală pentru contoare**. "Bine" este "pune numărul în cache"; "excelent" este să faci buffering la *scrieri* — recunoscând că blocajul este contenția pe scriere pe un rând fierbinte, nu încărcarea de citire. Ei sondează compromisul: este acceptabil un număr aproximativ? Pentru numărul de vizualizări, da — nimeni nu observă 1.203.428 vs 1.203.450. Capcana este să te îngrijorezi de numere exacte și să apelezi la o tranzacție, reintroducând lock-ul pe care îl evitai.

## Compromisuri și eșecuri

- **Acuratețe vs throughput**: numerele exacte necesită seturi de dedup (consumatoare de memorie); HyperLogLog-ul aproximativ este mic și rapid. Alege per funcționalitate — aprecierile sunt exacte, numerele de vizualizări pot fi aproximative.
- **Durabilitate**: Redis este in-memory. Dacă moare înainte de un flush, pierzi delta ne-golită. Activează AOF și menține ferestrele de flush scurte (secunde) pentru a limita pierderea; totalul din DB plus un mic decalaj este acceptabil pentru un contor de vizualizări.
- **Cheie fierbinte**: o postare virală concentrează tot traficul pe o singură cheie Redis. Fă-i sharding în `views:{post}:{0..9}` și însumează la citire, sau rutează cheile fierbinți către un nod dedicat, astfel încât o postare să nu poată satura shard-ul.

Arhitectură

Componente și flux

Perspectiva de interviu

Compromisuri și eșecuri

Întrebări conexe