Hur bygger du en realtidsräknare för visningar/gillanden på virala inlägg?

Question

IT Interview Practice · Accepted Answer

Kör aldrig `UPDATE posts SET views = views + 1` per händelse på ett hett inlägg — den enda raden blir en låsflaskhals. **Inkrementera i Redis, batch-flusha till DB:n** var några sekunder, och läs antalet från Redis. DB:n lagrar hållbara totaler, inte livetrafik.

## Arkitektur

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

## Komponenter och flöde

- **Redis INCR** absorberar skrivstormen. En enda `INCR views:{post}` är atomisk och hanterar 100k+ ops/s på en nyckel — storleksordningar bortom en Postgres-rad. Denna räknare är källan till sanning för *läsningar*, så tittare ser siffran röra sig omedelbart.
- **Dedup för gillanden/unika visningar**: en rå räknare dubbelräknar uppdateringar. Använd `SADD seen:{post} {userId}` och `INCR` bara när tillägget är nytt; för billiga approximativa unika i massiv skala använd **HyperLogLog** (`PFADD`/`PFCOUNT`) — några KB uppskattar miljoner unika inom ~2% fel.
- **Batchad flusher** tömmer periodiskt delta till DB:n: `UPDATE posts SET views = views + delta`. Att flusha var 5:e sekund eller var N:e inkrement förvandlar en miljon skrivningar till en handfull — DB:n håller den hållbara totalen för kalla inlägg och analys.
- **Läsvägen** serveras från Redis; vid en cache miss läser den DB-totalen och värmer om Redis. Gillanden behöver per-användar-tillstånd (gillade *jag* det), så lagra mängden, inte bara ett tal.

## Intervjuperspektiv

Intervjuare testar om du accepterar **eventual consistency för antal**. "Bra" är "cacha antalet"; "utmärkt" är att buffra *skrivningar* — att inse att flaskhalsen är skrivcontention på en het rad, inte läslast. De undersöker avvägningen: är ett approximativt antal acceptabelt? För visningsantal, ja — ingen märker 1 203 428 mot 1 203 450. Fällan är att oroa sig för exakta antal och gripa efter en transaktion, vilket återinför låset du undvek.

## Avvägningar och fel

- **Noggrannhet vs throughput**: exakta antal behöver dedup-mängder (minnestunga); approximativ HyperLogLog är liten och snabb. Välj per feature — gillanden är exakta, visningsantal kan vara approximativa.
- **Hållbarhet**: Redis är in-memory. Om den dör innan en flush förlorar du det oflushade deltat. Aktivera AOF och håll flush-fönstren korta (sekunder) för att begränsa förlusten; DB-totalen plus ett litet glapp är acceptabelt för en visningsräknare.
- **Het nyckel**: ett viralt inlägg koncentrerar all trafik på en Redis-nyckel. Sharda den i `views:{post}:{0..9}` och summera vid läsning, eller dirigera heta nycklar till en dedikerad nod så att ett inlägg inte kan mätta sharden.

Arkitektur

Komponenter och flöde

Intervjuperspektiv

Avvägningar och fel

Relaterade frågor