Come costruisci un contatore di visualizzazioni/like in tempo reale per post virali?

Question

IT Interview Practice · Accepted Answer

Non fare mai `UPDATE posts SET views = views + 1` per ogni evento su un post caldo: quella singola riga diventa un collo di bottiglia da lock. **Incrementa in Redis, fai flush a batch verso il DB** ogni pochi secondi e leggi il conteggio da Redis. Il DB conserva i totali durevoli, non il traffico live.

## Architettura

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

## Componenti e flusso

- **Redis INCR** assorbe la tempesta di scritture. Un singolo `INCR views:{post}` è atomico e gestisce 100k+ operazioni/s su una chiave, ordini di grandezza oltre una riga di Postgres. Questo contatore è la fonte di verità per le *letture*, così gli spettatori vedono il numero muoversi istantaneamente.
- **Dedup per like/visualizzazioni uniche**: un contatore grezzo conta due volte i refresh. Usa `SADD seen:{post} {userId}` e fai `INCR` solo quando l'aggiunta è nuova; per uniche approssimate a basso costo su scala enorme usa **HyperLogLog** (`PFADD`/`PFCOUNT`): pochi KB stimano milioni di uniche con un errore di ~2%.
- **Flusher a batch** drena periodicamente il delta verso il DB: `UPDATE posts SET views = views + delta`. Fare flush ogni 5s o ogni N incrementi trasforma un milione di scritture in una manciata: il DB conserva il totale durevole per i post freddi e l'analytics.
- **Percorso di lettura** serve da Redis; in caso di cache miss legge il totale dal DB e riscalda Redis. I like richiedono stato per-utente (l'ho messo *io* il like?), quindi memorizza il set, non solo un numero.

## Prospettiva del colloquio

Gli intervistatori verificano se accetti la **consistenza eventuale per i conteggi**. "Buono" è "metti in cache il conteggio"; "eccellente" è bufferizzare le *scritture*, riconoscendo che il collo di bottiglia è la contesa in scrittura su una riga calda, non il carico di lettura. Sondano il compromesso: un conteggio approssimato è accettabile? Per i conteggi di visualizzazioni sì, nessuno nota 1.203.428 vs 1.203.450. La trappola è preoccuparsi dei conteggi esatti e ricorrere a una transazione, reintroducendo il lock che stavi evitando.

## Compromessi e modalità di guasto

- **Accuratezza vs throughput**: i conteggi esatti richiedono dedup set (pesanti in memoria); HyperLogLog approssimato è minuscolo e veloce. Scegli per feature: i like sono esatti, i conteggi di visualizzazioni possono essere approssimati.
- **Durabilità**: Redis è in memoria. Se muore prima di un flush, perdi il delta non ancora scaricato. Abilita AOF e mantieni brevi le finestre di flush (secondi) per limitare la perdita; il totale del DB più un piccolo gap è accettabile per un contatore di visualizzazioni.
- **Hot key**: un post virale concentra tutto il traffico su una sola chiave Redis. Fai sharding in `views:{post}:{0..9}` e somma in lettura, oppure instrada le chiavi calde verso un nodo dedicato così che un post non possa saturare lo shard.

Architettura

Componenti e flusso

Prospettiva del colloquio

Compromessi e modalità di guasto

Domande correlate