Unajengaje view/like counter ya real-time kwa posts za viral?

Question

IT Interview Practice · Accepted Answer

Kamwe usifanye `UPDATE posts SET views = views + 1` kwa kila tukio kwenye post moto — row hiyo moja huwa lock bottleneck. **Ongeza katika Redis, na flush kwa batch kwenda DB** kila sekunde chache, na soma idadi kutoka Redis. DB huhifadhi jumla za kudumu, si traffic ya moja kwa moja.

## Usanifu

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

## Vipengele na mtiririko

- **Redis INCR** hunyonya dhoruba ya writes. `INCR views:{post}` moja ni atomic na hushughulikia ops 100k+ kwa sekunde kwenye key moja — mara nyingi zaidi ya row ya Postgres. Counter hii ndiyo chanzo cha ukweli kwa *reads*, hivyo watazamaji huona namba ikisonga papo hapo.
- **Dedup kwa likes/unique views**: counter ghafi huhesabu refreshes mara mbili. Tumia `SADD seen:{post} {userId}` na `INCR` tu wakati ongezeko ni jipya; kwa uniques za makadirio nafuu kwenye scale kubwa tumia **HyperLogLog** (`PFADD`/`PFCOUNT`) — KB chache hukadiria mamilioni ya uniques ndani ya makosa ~2%.
- **Batched flusher** hutoa delta kwa DB mara kwa mara: `UPDATE posts SET views = views + delta`. Kuflush kila sekunde 5 au kila ongezeko N hubadilisha writes milioni kuwa chache — DB hushikilia jumla ya kudumu kwa cold posts na analytics.
- **Read path** hutumikia kutoka Redis; kwenye cache miss husoma jumla ya DB na kupasha joto Redis tena. Likes zinahitaji hali ya kila mtumiaji (je *mimi* niliipenda), hivyo hifadhi set, si namba tu.

## Mtazamo wa mahojiano

Wahojiwa hupima kama unakubali **eventual consistency kwa hesabu**. "Nzuri" ni "cache the count"; "bora sana" ni ku-buffer *writes* — kutambua kuwa bottleneck ni write contention kwenye row moto, si read load. Huchunguza maelewano: je hesabu ya makadirio inakubalika? Kwa view counts, ndiyo — hakuna anayegundua 1,203,428 dhidi ya 1,203,450. Mtego ni kuwa na wasiwasi kuhusu hesabu kamili na kukimbilia transaction, ukirudisha lock uliokuwa unaepuka.

## Maelewano na hitilafu

- **Usahihi vs throughput**: hesabu kamili zinahitaji dedup sets (nzito kwa memory); HyperLogLog ya makadirio ni ndogo na ya haraka. Chagua kwa kila kipengele — likes ni kamili, view counts zinaweza kuwa za makadirio.
- **Durability**: Redis ni in-memory. Ikifa kabla ya flush, unapoteza delta isiyoflushiwa. Wezesha AOF na weka madirisha ya flush mafupi (sekunde) ili kupunguza hasara; jumla ya DB pamoja na pengo dogo inakubalika kwa view counter.
- **Hot key**: post ya viral hukusanya traffic yote kwenye Redis key moja. Igawe (shard) kuwa `views:{post}:{0..9}` na jumlisha wakati wa read, au elekeza hot keys kwenye node maalum ili post moja isijae shard.

Usanifu

Vipengele na mtiririko

Mtazamo wa mahojiano

Maelewano na hitilafu

Maswali yanayohusiana