Kif tibni counter ta' views/likes f'real-time għal posts virali?

Question

IT Interview Practice · Accepted Answer

Qatt m'għandek tagħmel `UPDATE posts SET views = views + 1` għal kull event fuq post jaħraq — dak il-post wieħed isir lock bottleneck. **Żid f'Redis, agħmel batch-flush għad-DB** kull ftit sekondi, u aqra l-għadd minn Redis. Id-DB jaħżen totals durabbli, mhux traffiku live.

## Arkitettura

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

## Komponenti u fluss

- **Redis INCR** jassorbi l-maltempata ta' kitba. `INCR views:{post}` waħdu huwa atomiku u jimmaniġġja 100k+ ops/s fuq key wieħed — ordnijiet ta' kobor lil hinn minn post ta' Postgres. Dan il-counter huwa s-sors tal-verità għal *reads*, allura l-udjenza tara n-numru jiċċaqlaq mill-ewwel.
- **Dedup għal likes/unique views**: counter mhux ipproċessat jgħodd refreshes darbtejn. Uża `SADD seen:{post} {userId}` u `INCR` biss meta ż-żieda hija ġdida; għal unique approssimattivi rħas fuq skala massiva uża **HyperLogLog** (`PFADD`/`PFCOUNT`) — ftit KB jistimaw miljuni ta' unique fi ħdan ~2% żball.
- **Batched flusher** perjodikament ibattal id-delta lejn id-DB: `UPDATE posts SET views = views + delta`. Flushing kull 5s jew kull N increments ibiddel miljun kitba f'ftit — id-DB iżomm it-total durabbli għal posts kesħin u analytics.
- **Read path** iservi minn Redis; fuq cache miss jaqra t-total tad-DB u jerġa' jsaħħan Redis. Il-likes jeħtieġu state għal kull utent (jien għoġobni?), allura aħżen is-set, mhux biss numru.

## Perspettiva tal-intervista

L-intervistaturi jittestjaw jekk taċċettax **eventual consistency għall-għadd**. "Tajjeb" huwa "ikkaċċja l-għadd"; "eċċellenti" huwa buffering ta' *writes* — li tirrikonoxxi li l-bottleneck huwa write contention fuq post jaħraq, mhux read load. Jgħarblu t-trade: għadd approssimattiv huwa aċċettabbli? Għal view counts, iva — ħadd ma jinnota 1,203,428 vs 1,203,450. In-nassa hija li tinkwieta dwar għadd eżatt u taqbad transaction, u terġa' ddaħħal il-lock li kont qed tevita.

## Trade-offs u fallimenti

- **Preċiżjoni vs throughput**: għadd eżatt jeħtieġ dedup sets (tqal fil-memorja); HyperLogLog approssimattiv huwa żgħir u mgħaġġel. Agħżel għal kull feature — il-likes huma eżatti, view counts jistgħu jkunu approssimattivi.
- **Durabbiltà**: Redis huwa in-memory. Jekk imut qabel flush, titlef id-delta mhux flushjat. Attiva AOF u żomm il-flush windows qosra (sekondi) biex tillimita t-telf; it-total tad-DB flimkien ma' gap żgħir huwa aċċettabbli għal view counter.
- **Hot key**: post virali jikkonċentra t-traffiku kollu fuq key wieħed ta' Redis. Ippartizzjonah f'`views:{post}:{0..9}` u aggrega mal-qari, jew iddawwar hot keys lejn node dedikat biex post wieħed ma jkunx jista' jissatura x-shard.

Arkitettura

Komponenti u fluss

Perspettiva tal-intervista

Trade-offs u fallimenti

Mistoqsijiet relatati