Jak postavíte real-time čítač zhlédnutí/lajků pro virální příspěvky?

Question

IT Interview Practice · Accepted Answer

Nikdy nedělejte `UPDATE posts SET views = views + 1` na každou událost u hot příspěvku — z toho jednoho řádku se stane úzké hrdlo se zámkem. **Inkrementujte v Redisu, dávkově flushujte do DB** každých pár sekund a čtěte počet z Redisu. DB uchovává trvanlivé součty, nikoli živý provoz.

## Architektura

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

## Komponenty a tok

- **Redis INCR** pohltí bouři zápisů. Jediný `INCR views:{post}` je atomický a zvládne 100k+ operací/s na jednom klíči — o řády víc než řádek v Postgresu. Tento čítač je zdrojem pravdy pro *čtení*, takže diváci vidí, jak se číslo mění okamžitě.
- **Dedup pro lajky/unikátní zhlédnutí**: syrový čítač počítá refreshe dvakrát. Použijte `SADD seen:{post} {userId}` a `INCR` proveďte, jen když je přidání nové; pro levné přibližné uniques v masivním měřítku použijte **HyperLogLog** (`PFADD`/`PFCOUNT`) — pár KB odhadne miliony uniques s chybou ~2 %.
- **Dávkový flusher** periodicky vylévá deltu do DB: `UPDATE posts SET views = views + delta`. Flushování každých 5 s nebo každých N inkrementů promění milion zápisů v hrstku — DB drží trvanlivý součet pro studené příspěvky a analytiku.
- **Read path** obsluhuje z Redisu; při cache miss přečte součet z DB a znovu zahřeje Redis. Lajky potřebují stav na uživatele (lajkl jsem *já*), takže ukládejte set, ne jen číslo.

## Pohled z pohovoru

Tazatelé testují, zda akceptujete **eventual consistency u počtů**. „Dobré“ je „nacachuj počet“; „skvělé“ je bufferovat *zápisy* — rozpoznat, že úzkým hrdlem je contention zápisů na hot row, nikoli zátěž čtení. Zkoumají kompromis: je přibližný počet přijatelný? U počtů zhlédnutí ano — nikdo si nevšimne 1 203 428 vs 1 203 450. Pastí je trápit se přesnými počty a sáhnout po transakci, čímž znovu zavedete zámek, kterému jste se vyhýbali.

## Kompromisy a selhání

- **Přesnost vs throughput**: přesné počty potřebují dedup sety (náročné na paměť); přibližný HyperLogLog je maličký a rychlý. Volte podle feature — lajky jsou přesné, počty zhlédnutí mohou být přibližné.
- **Trvanlivost (durability)**: Redis je in-memory. Pokud padne před flushem, ztratíte nevyflushnutou deltu. Zapněte AOF a držte flush okna krátká (sekundy), abyste omezili ztrátu; součet v DB plus malá mezera je pro čítač zhlédnutí přijatelný.
- **Hot key**: virální příspěvek koncentruje veškerý provoz na jeden Redis klíč. Rozdělte ho na `views:{post}:{0..9}` a při čtení sečtěte, nebo směrujte hot keys na dedikovaný node, aby jeden příspěvek nezahltil shard.

Architektura

Komponenty a tok

Pohled z pohovoru

Kompromisy a selhání

Související otázky