Hvordan bygger du en real-time view/like-tæller til virale opslag?

Question

IT Interview Practice · Accepted Answer

Kør aldrig `UPDATE posts SET views = views + 1` pr. event på et hot opslag — den ene row bliver en lock-flaskehals. **Increment i Redis, batch-flush til DB'en** hvert par sekunder, og læs tælleren fra Redis. DB'en gemmer holdbare totaler, ikke live-trafik.

## 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 og flow

- **Redis INCR** absorberer write-stormen. En enkelt `INCR views:{post}` er atomar og håndterer 100k+ ops/s på én nøgle — størrelsesordener forbi en Postgres-row. Denne tæller er kilden til sandhed for *reads*, så seere ser tallet bevæge sig øjeblikkeligt.
- **Dedup for likes/unikke views**: en rå tæller dobbelttæller refreshes. Brug `SADD seen:{post} {userId}` og `INCR` kun når tilføjelsen er ny; for billige omtrentlige unikke i massiv skala brug **HyperLogLog** (`PFADD`/`PFCOUNT`) — få KB estimerer millioner af unikke inden for ~2% fejl.
- **Batched flusher** dræner periodisk deltaen til DB'en: `UPDATE posts SET views = views + delta`. At flushe hvert 5. sekund eller hver N increments gør en million writes til en håndfuld — DB'en holder den holdbare total for kolde opslag og analytics.
- **Read path** serverer fra Redis; ved en cache miss læser den DB-totalen og genopvarmer Redis. Likes kræver tilstand pr. bruger (likede *jeg* det), så gem settet, ikke bare et tal.

## Interview-perspektiv

Interviewere tester, om du accepterer **eventual consistency for tællere**. "Godt" er "cache tælleren"; "fremragende" er at buffere *writes* — at erkende, at flaskehalsen er write-kontention på en hot row, ikke read-belastning. De undersøger trade-off'et: er en omtrentlig tæller acceptabel? For view-tællere, ja — ingen bemærker 1.203.428 vs 1.203.450. Fælden er at bekymre sig om nøjagtige tællere og gribe efter en transaction, hvilket genindfører den lock, du undgik.

## Trade-offs og fejl

- **Nøjagtighed vs throughput**: nøjagtige tællere kræver dedup-sets (hukommelsestunge); omtrentlig HyperLogLog er lille og hurtig. Vælg pr. feature — likes er nøjagtige, view-tællere kan være omtrentlige.
- **Durability**: Redis er in-memory. Hvis den dør før en flush, mister du den ikke-flushede delta. Aktivér AOF og hold flush-vinduer korte (sekunder) for at begrænse tabet; DB-totalen plus et lille gab er acceptabelt for en view-tæller.
- **Hot key**: et viralt opslag koncentrerer al trafik på én Redis-nøgle. Shard den til `views:{post}:{0..9}` og summér ved read, eller rout hot keys til en dedikeret node, så ét opslag ikke kan mætte sharden.

Arkitektur

Komponenter og flow

Interview-perspektiv

Trade-offs og fejl

Relaterede spørgsmål