Ta yaya za ka gina real-time view/like counter ga posts masu yaɗuwa (viral)?

Question

IT Interview Practice · Accepted Answer

Kada ka taɓa yin `UPDATE posts SET views = views + 1` ga kowane event a post mai zafi — wannan row ɗaya yana zama lock bottleneck. **Ƙara a Redis, batch-flush zuwa DB** kowane 'yan daƙiƙu, kuma ka karanta adadin daga Redis. DB yana adana jimlar durable, ba live traffic ba.

## Gine-gine

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

## Sassa da gudanawa

- **Redis INCR** yana ɗauke da guguwar rubutu. `INCR views:{post}` ɗaya atomic ne kuma yana sarrafa ops 100k+ a daƙiƙa a key ɗaya — matakai da yawa sama da Postgres row. Wannan counter shi ne tushen gaskiya ga *reads*, don haka masu kallo suna ganin lambar tana motsi nan take.
- **Dedup ga likes/unique views**: counter mara kyau yana ƙidaya refreshes sau biyu. Yi amfani da `SADD seen:{post} {userId}` kuma ka `INCR` kawai idan ƙarawa sabo ne; don approximate uniques masu arha a babban sikeli yi amfani da **HyperLogLog** (`PFADD`/`PFCOUNT`) — KB kaɗan suna kimanta miliyoyin uniques cikin kuskuren kusan 2%.
- **Batched flusher** yana zubar da delta zuwa DB lokaci-lokaci: `UPDATE posts SET views = views + delta`. Flushing kowane 5s ko kowane N increments yana mai da rubuce-rubuce miliyan zuwa 'yan kaɗan — DB yana riƙe jimlar durable ga cold posts da analytics.
- **Read path** yana bauta daga Redis; a cache miss yana karanta jimlar DB kuma yana sake dumama Redis. Likes suna buƙatar per-user state (shin *ni* na yi like), don haka ka adana set ɗin, ba lamba kawai ba.

## Ra'ayin hira

Masu yin hira suna gwada ko ka karɓi **eventual consistency ga counts**. "Mai kyau" shi ne "cache adadin"; "mai kyau sosai" shi ne yin buffer na *writes* — fahimtar cewa bottleneck ɗin shi ne write contention a row mai zafi, ba read load ba. Suna bincike sulhun: shin approximate count abin karɓa ne? Ga view counts, e — babu wanda ke lura da 1,203,428 vs 1,203,450. Tarkon shi ne damuwa game da ainihin counts kuma ka nemi transaction, wanda ke sake kawo lock ɗin da kake gujewa.

## Sulhu da gazawa

- **Daidaito vs throughput**: ainihin counts suna buƙatar dedup sets (masu nauyin memory); approximate HyperLogLog ƙarami ne kuma mai sauri. Zaɓi ga kowane fasali — likes ainihi ne, view counts na iya zama approximate.
- **Durability**: Redis in-memory ne. Idan ya mutu kafin flush, kana rasa delta ɗin da ba a flush ba. Kunna AOF kuma ka ajiye flush windows gajere (daƙiƙu) don iyakance asara; jimlar DB tare da ƙaramin gibi abin karɓa ne ga view counter.
- **Hot key**: post mai yaɗuwa yana tattara duk traffic a Redis key ɗaya. Yi shard shi zuwa `views:{post}:{0..9}` kuma ka sum a lokacin read, ko ka tura hot keys zuwa node na musamman domin post ɗaya kada ya cika shard.

Gine-gine

Sassa da gudanawa

Ra'ayin hira

Sulhu da gazawa

Tambayoyi masu alaƙa