Wie baust du einen Echtzeit-View-/Like-Zähler für virale Posts?

Question

IT Interview Practice · Accepted Answer

Führe niemals pro Event ein `UPDATE posts SET views = views + 1` auf einem heißen Post aus - diese eine Row wird zum Lock-Engpass. **Inkrementiere in Redis, flushe im Batch in die DB** alle paar Sekunden und lies den Zähler aus Redis. Die DB speichert langlebige Gesamtwerte, nicht den Live-Traffic.

## Architektur

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

## Komponenten und Ablauf

- **Redis INCR** absorbiert den Write-Sturm. Ein einzelnes `INCR views:{post}` ist atomar und bewältigt 100k+ Ops/s auf einem Key - Größenordnungen jenseits einer Postgres-Row. Dieser Zähler ist die Source of Truth für *Reads*, sodass Betrachter die Zahl sofort steigen sehen.
- **Dedup für Likes/eindeutige Views**: Ein roher Zähler zählt Reloads doppelt. Nutze `SADD seen:{post} {userId}` und `INCR` nur, wenn das Add neu ist; für günstige, näherungsweise eindeutige Werte bei massivem Maßstab nutze **HyperLogLog** (`PFADD`/`PFCOUNT`) - wenige KB schätzen Millionen von Uniques mit ~2% Fehler.
- **Batched Flusher** leert das Delta periodisch in die DB: `UPDATE posts SET views = views + delta`. Ein Flush alle 5s oder alle N Inkremente macht aus einer Million Writes eine Handvoll - die DB hält den langlebigen Gesamtwert für kalte Posts und Analytics.
- **Read-Pfad** liefert aus Redis; bei einem Cache Miss liest er den DB-Gesamtwert und wärmt Redis neu auf. Likes benötigen Per-User-State (habe *ich* geliked), also speichere das Set, nicht nur eine Zahl.

## Interview-Perspektive

Interviewer prüfen, ob du **Eventual Consistency für Zähler** akzeptierst. "Gut" ist "den Zähler cachen"; "hervorragend" ist das Puffern von *Writes* - zu erkennen, dass der Engpass Write-Contention auf einer Hot Row ist, nicht die Read-Last. Sie sondieren den Trade-off: Ist ein näherungsweiser Zähler akzeptabel? Für View-Counts ja - niemand bemerkt 1.203.428 vs. 1.203.450. Die Falle ist, sich um exakte Zähler zu sorgen und zu einer Transaktion zu greifen, wodurch der Lock, den du vermeiden wolltest, wieder eingeführt wird.

## Trade-offs und Fehlerfälle

- **Genauigkeit vs. Throughput**: Exakte Zähler brauchen Dedup-Sets (speicherintensiv); näherungsweises HyperLogLog ist winzig und schnell. Wähle pro Feature - Likes sind exakt, View-Counts dürfen näherungsweise sein.
- **Durability**: Redis ist in-memory. Stirbt es vor einem Flush, verlierst du das ungeflushte Delta. Aktiviere AOF und halte die Flush-Fenster kurz (Sekunden), um den Verlust zu begrenzen; der DB-Gesamtwert plus eine kleine Lücke ist für einen View-Counter akzeptabel.
- **Hot Key**: Ein viraler Post konzentriert den gesamten Traffic auf einen Redis-Key. Sharde ihn in `views:{post}:{0..9}` und summiere beim Lesen, oder route Hot Keys auf einen dedizierten Node, damit ein Post den Shard nicht sättigen kann.

Architektur

Komponenten und Ablauf

Interview-Perspektive

Trade-offs und Fehlerfälle

Ähnliche Fragen