Hoe bouw je een real-time view/like-teller voor virale posts?

Question

IT Interview Practice · Accepted Answer

Doe nooit `UPDATE posts SET views = views + 1` per event op een hot post — die ene row wordt een lock-bottleneck. **Verhoog in Redis, flush in batches naar de DB** om de paar seconden, en lees de teller uit Redis. De DB bewaart duurzame totalen, niet live verkeer.

## Architectuur

```text
Client tap ─▶ API ─▶ Redis INCR views:{post}   (live, source of truth voor reads)
                          │            └── dedup: SADD seen:{post} {user/ip}
                          ▼
                 elke ~5s / N ops
              Flusher ─▶ UPDATE posts SET views = views + delta   (duurzaam)
                          ▲
                 read-pad: GET Redis (fallback DB bij miss)
```

## Componenten en flow

- **Redis INCR** absorbeert de write-storm. Eén `INCR views:{post}` is atomair en verwerkt 100k+ ops/s op één key — ordes van grootte meer dan een Postgres row. Deze teller is de source of truth voor *reads*, zodat kijkers het getal direct zien bewegen.
- **Dedup voor likes/unieke views**: een ruwe teller telt refreshes dubbel. Gebruik `SADD seen:{post} {userId}` en `INCR` alleen wanneer de toevoeging nieuw is; voor goedkope benaderende unieke waarden op enorme schaal gebruik je **HyperLogLog** (`PFADD`/`PFCOUNT`) — een paar KB schat miljoenen unieke waarden binnen ~2% foutmarge.
- **Batched flusher** draineert periodiek de delta naar de DB: `UPDATE posts SET views = views + delta`. Flushen om de 5s of om de N verhogingen zet een miljoen writes om in een handvol — de DB houdt het duurzame totaal voor koude posts en analytics.
- **Read-pad** serveert vanuit Redis; bij een cache miss leest het het DB-totaal en warmt Redis opnieuw op. Likes hebben per-user state nodig (heb *ik* geliket), dus sla de set op, niet alleen een getal.

## Interviewperspectief

Interviewers testen of je **eventual consistency voor tellers** accepteert. "Goed" is "cache de teller"; "uitstekend" is het bufferen van *writes* — inzien dat de bottleneck write-contentie op een hot row is, niet read-belasting. Ze peilen de afweging: is een benaderende teller acceptabel? Voor view counts, ja — niemand merkt het verschil tussen 1.203.428 en 1.203.450. De valkuil is je druk maken om exacte tellingen en grijpen naar een transactie, waarmee je de lock die je vermeed opnieuw introduceert.

## Afwegingen en faalmodi

- **Nauwkeurigheid versus throughput**: exacte tellingen hebben dedup-sets nodig (geheugenintensief); benaderende HyperLogLog is klein en snel. Kies per feature — likes zijn exact, view counts mogen benaderend zijn.
- **Duurzaamheid**: Redis is in-memory. Als het sterft vóór een flush, verlies je de niet-geflushte delta. Zet AOF aan en houd flush-vensters kort (seconden) om het verlies te begrenzen; het DB-totaal plus een klein gat is acceptabel voor een view-teller.
- **Hot key**: een virale post concentreert al het verkeer op één Redis key. Shard hem in `views:{post}:{0..9}` en sommeer bij het lezen, of route hot keys naar een dedicated node zodat één post de shard niet kan verzadigen.

Architectuur

Componenten en flow

Interviewperspectief

Afwegingen en faalmodi

Gerelateerde vragen