તમે viral posts માટે real-time view/like counter કેવી રીતે બનાવશો?

Question

IT Interview Practice · Accepted Answer

એક hot post પર પ્રતિ event ક્યારેય `UPDATE posts SET views = views + 1` ન કરો — તે એક row lock bottleneck બની જાય છે. **Redis માં increment કરો, દર થોડી સેકન્ડે DB પર batch-flush કરો**, અને count Redis માંથી વાંચો. DB durable totals સ્ટોર કરે છે, live traffic નહીં.

## આર્કિટેક્ચર

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

## કમ્પોનન્ટ્સ અને flow

- **Redis INCR** write storm ને શોષી લે છે. એક જ `INCR views:{post}` atomic છે અને એક key પર 100k+ ops/s સંભાળે છે — Postgres row કરતાં અનેક ગણું વધારે. આ counter *reads* માટે source of truth છે, તેથી viewers number ને તરત જ ખસતું જુએ છે.
- **likes/unique views માટે Dedup**: raw counter refreshes ને double-count કરે છે. `SADD seen:{post} {userId}` વાપરો અને add નવો હોય ત્યારે જ `INCR` કરો; મોટા scale પર સસ્તા approximate uniques માટે **HyperLogLog** (`PFADD`/`PFCOUNT`) વાપરો — થોડા KB ~2% error ની અંદર લાખો uniques અંદાજે છે.
- **Batched flusher** સમયાંતરે delta ને DB પર drain કરે છે: `UPDATE posts SET views = views + delta`. દર 5s અથવા દર N increments flush કરવાથી લાખો writes થોડાક માં ફેરવાય છે — DB cold posts અને analytics માટે durable total રાખે છે.
- **Read path** Redis માંથી serve કરે છે; cache miss પર તે DB total વાંચે છે અને Redis ને ફરી warm કરે છે. Likes ને પ્રતિ-યુઝર state જોઈએ (શું *મેં* like કર્યું), તેથી માત્ર number નહીં, set સ્ટોર કરો.

## ઇન્ટરવ્યૂ દૃષ્ટિકોણ

ઇન્ટરવ્યૂઅર્સ તપાસે છે કે તમે **counts માટે eventual consistency** સ્વીકારો છો કે નહીં. "Good" એ છે "count cache કરો"; "great" એ *writes* buffer કરવું છે — ઓળખવું કે bottleneck એ hot row પર write contention છે, read load નહીં. તેઓ trade ને probe કરે છે: શું approximate count સ્વીકાર્ય છે? view counts માટે, હા — કોઈ 1,203,428 vs 1,203,450 ધ્યાનમાં લેતું નથી. Trap એ exact counts ની ચિંતા કરવાનું અને transaction તરફ પહોંચવાનું છે, જે તમે ટાળી રહ્યા હતા તે lock ફરીથી લાવે છે.

## Trade-offs અને failure

- **Accuracy vs throughput**: exact counts ને dedup sets જોઈએ (memory-heavy); approximate HyperLogLog નાનું અને ઝડપી છે. પ્રતિ feature પસંદ કરો — likes exact છે, view counts approximate હોઈ શકે.
- **Durability**: Redis in-memory છે. જો flush પહેલાં તે મરી જાય, તો તમે un-flushed delta ગુમાવો છો. AOF enable કરો અને flush windows ટૂંકા (સેકન્ડ્સ) રાખો જેથી loss bound રહે; view counter માટે DB total વત્તા નાનું gap સ્વીકાર્ય છે.
- **Hot key**: એક viral post બધો traffic એક Redis key પર કેન્દ્રિત કરે છે. તેને `views:{post}:{0..9}` માં shard કરો અને read પર sum કરો, અથવા hot keys ને dedicated node પર route કરો જેથી એક post shard ને saturate ન કરી શકે.

આર્કિટેક્ચર

કમ્પોનન્ટ્સ અને flow

ઇન્ટરવ્યૂ દૃષ્ટિકોણ

Trade-offs અને failure

સંબંધિત પ્રશ્નો