Hvordan bygger du en sanntids visnings-/like-teller for virale innlegg?

Question

IT Interview Practice · Accepted Answer

Aldri `UPDATE posts SET views = views + 1` per event på et hot innlegg — den ene raden blir en lock-flaskehals. **Inkrementer i Redis, batch-flush til DB-en** hvert par sekunder, og les tellingen fra Redis. DB-en lagrer varige totaler, ikke live trafikk.

## Arkitektur

```text
Klient-tap ─▶ API ─▶ Redis INCR views:{post}   (live, sannhetskilde for lesninger)
                          │            └── dedup: SADD seen:{post} {user/ip}
                          ▼
                 hvert ~5s / N ops
              Flusher ─▶ UPDATE posts SET views = views + delta   (varig)
                          ▲
                 lese-sti: GET Redis (fallback DB ved miss)
```

## Komponenter og flyt

- **Redis INCR** absorberer write-stormen. En enkelt `INCR views:{post}` er atomisk og håndterer 100k+ ops/s på én key — størrelsesordener forbi en Postgres-rad. Denne telleren er sannhetskilden for *lesninger*, så seere ser tallet bevege seg umiddelbart.
- **Dedup for likes/unike visninger**: en rå teller dobbelttteller refreshes. Bruk `SADD seen:{post} {userId}` og `INCR` kun når add-en er ny; for billige tilnærmede unike i massiv skala bruk **HyperLogLog** (`PFADD`/`PFCOUNT`) — noen få KB estimerer millioner av unike innen ~2% feil.
- **Batchet flusher** tømmer periodisk delta-en til DB-en: `UPDATE posts SET views = views + delta`. Flushing hvert 5s eller hver N inkrementer gjør en million writes til en håndfull — DB-en holder den varige totalen for kalde innlegg og analytics.
- **Lese-sti** serverer fra Redis; ved en cache miss leser den DB-totalen og re-varmer Redis. Likes trenger per-bruker-state (likte *jeg* det), så lagre settet, ikke bare et tall.

## Intervjuperspektiv

Intervjuere tester om du aksepterer **eventual consistency for tellinger**. "Bra" er "cache tellingen"; "utmerket" er å buffre *writes* — å erkjenne at flaskehalsen er write-contention på en hot row, ikke lesebelastning. De undersøker avveiningen: er en tilnærmet telling akseptabel? For visningstellinger, ja — ingen legger merke til 1 203 428 vs 1 203 450. Fellen er å bekymre seg om eksakte tellinger og gripe til en transaksjon, som gjeninnfører låsen du unngikk.

## Avveininger og feil

- **Nøyaktighet vs throughput**: eksakte tellinger trenger dedup-sett (minnetunge); tilnærmet HyperLogLog er lite og raskt. Velg per feature — likes er eksakte, visningstellinger kan være tilnærmede.
- **Varighet**: Redis er in-memory. Hvis den dør før en flush, mister du den uflusha delta-en. Aktiver AOF og hold flush-vinduene korte (sekunder) for å begrense tapet; DB-totalen pluss et lite gap er akseptabelt for en visningsteller.
- **Hot key**: et viralt innlegg konsentrerer all trafikk på én Redis-key. Shard den til `views:{post}:{0..9}` og summer ved lesning, eller rut hot keys til en dedikert node slik at ett innlegg ikke kan mette sharden.

Arkitektur

Komponenter og flyt

Intervjuperspektiv

Avveininger og feil

Relaterte spørsmål