Si ndërtoni një counter view/like në kohë reale për postime virale?

Question

IT Interview Practice · Accepted Answer

Kurrë mos bëni `UPDATE posts SET views = views + 1` për çdo event në një post të nxehtë — ai row i vetëm bëhet një bottleneck lock-u. **Increment në Redis, batch-flush në DB** çdo pak sekonda, dhe lexoni numrin nga Redis. DB ruan totalet e qëndrueshme, jo trafikun live.

## Arkitektura

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

## Komponentët dhe rrjedha

- **Redis INCR** thith stuhinë e shkrimeve. Një `INCR views:{post}` i vetëm është atomik dhe përballon 100k+ ops/s në një key — rendë të tëra madhësie mbi një row të Postgres. Ky counter është burimi i së vërtetës për *leximet*, kështu që shikuesit e shohin numrin të lëvizë menjëherë.
- **Dedup për likes/unique views**: një counter i papërpunuar numëron dy herë refresh-et. Përdorni `SADD seen:{post} {userId}` dhe bëni `INCR` vetëm kur shtimi është i ri; për unique afërsisht të lira në shkallë masive përdorni **HyperLogLog** (`PFADD`/`PFCOUNT`) — pak KB vlerëson miliona unique brenda ~2% gabimi.
- **Batched flusher** periodikisht zbraz delta-n në DB: `UPDATE posts SET views = views + delta`. Flush çdo 5s ose çdo N increments e kthen një milion shkrime në një grusht — DB mban totalin e qëndrueshëm për postimet e ftohta dhe analitikën.
- **Read path** shërben nga Redis; në një cache miss lexon totalin e DB dhe ri-ngroh Redis. Likes kanë nevojë për gjendje për çdo përdorues (a e pëlqeva *unë*), kështu që ruani set-in, jo thjesht një numër.

## Këndvështrimi i intervistës

Intervistuesit testojnë nëse pranoni **eventual consistency për numërimet**. "Mirë" është "cache numrin"; "e shkëlqyer" është buffering i *shkrimeve* — të kuptosh se bottleneck-u është write contention në një row të nxehtë, jo ngarkesa e leximit. Ata hetojnë kompromisin: a është i pranueshëm një numër i përafërt? Për view counts, po — askush nuk vëren 1,203,428 vs 1,203,450. Kurthi është të shqetësohesh për numra të saktë dhe të kapesh pas një transaction, duke rifutur lock-un që po e shmangje.

## Kompromiset dhe dështimi

- **Saktësia vs throughput**: numrat e saktë kanë nevojë për dedup sets (të rënda në memorie); HyperLogLog i përafërt është i vogël dhe i shpejtë. Zgjidhni për çdo veçori — likes janë të sakta, view counts mund të jenë të përafërt.
- **Durability**: Redis është in-memory. Nëse vdes para një flush, humbni delta-n e pa-flush-uar. Aktivizoni AOF dhe mbani dritaret e flush të shkurtra (sekonda) për të kufizuar humbjen; totali i DB plus një hendek i vogël është i pranueshëm për një view counter.
- **Hot key**: një post viral përqendron gjithë trafikun në një key Redis. Shard-oni në `views:{post}:{0..9}` dhe mblidhni gjatë leximit, ose drejtoni key-t e nxehtë te një node i dedikuar që një post të mos ngopë shard-in.

Arkitektura

Komponentët dhe rrjedha

Këndvështrimi i intervistës

Kompromiset dhe dështimi

Pyetje të ngjashme