వైరల్ 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 నుండి read చేయండి. DB live traffic కాదు, durable totals ను store చేస్తుంది.

## ఆర్కిటెక్చర్

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

## కాంపోనెంట్‌లు మరియు ఫ్లో

- **Redis INCR** write storm ను శోషిస్తుంది. ఒక్క `INCR views:{post}` atomic మరియు ఒక key పై 100k+ ops/s ను handle చేస్తుంది — ఒక Postgres row కంటే అనేక రెట్లు ఎక్కువ. ఈ counter *reads* కి ఏకైక సత్య మూలం, కాబట్టి viewers సంఖ్య వెంటనే కదలడం చూస్తారు.
- **likes/unique views కోసం Dedup**: ఒక raw counter refreshes ను double-count చేస్తుంది. `SADD seen:{post} {userId}` వాడండి మరియు add కొత్తది అయినప్పుడే `INCR` చేయండి; భారీ scale వద్ద చవకైన approximate uniques కోసం **HyperLogLog** (`PFADD`/`PFCOUNT`) వాడండి — కొన్ని KB లు ~2% error లోపు millions of uniques ను estimate చేస్తాయి.
- **Batched flusher** periodically delta ను DB కి drain చేస్తుంది: `UPDATE posts SET views = views + delta`. ప్రతి 5s కి లేదా ప్రతి N increments కి flush చేయడం మిలియన్ writes ను కొన్నింటికి మారుస్తుంది — cold posts మరియు analytics కోసం DB durable total ను ఉంచుతుంది.
- **Read path** Redis నుండి serve చేస్తుంది; cache miss పై అది DB total ను read చేసి Redis ను re-warm చేస్తుంది. Likes కి per-user state అవసరం (*నేను* like చేశానా), కాబట్టి కేవలం సంఖ్య కాదు, set ను store చేయండి.

## ఇంటర్వ్యూ దృక్కోణం

మీరు **counts కోసం eventual consistency** ను అంగీకరిస్తారా అని ఇంటర్వ్యూయర్‌లు పరీక్షిస్తారు. "మంచిది" అంటే "count ను cache చేయండి"; "గొప్పది" అంటే *writes* ను buffer చేయడం — bottleneck read load కాదు, ఒక hot row పై write contention అని గుర్తించడం. వారు trade ను పరిశీలిస్తారు: approximate count అంగీకారమా? view counts కి, అవును — 1,203,428 vs 1,203,450 ఎవరూ గమనించరు. ఉచ్చు — exact counts గురించి ఆందోళన చెంది transaction కోసం చేరుకోవడం, మీరు తప్పించుకుంటున్న lock ను తిరిగి తీసుకురావడం.

## ట్రేడ్-ఆఫ్‌లు మరియు వైఫల్యం

- **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 ను చిన్నగా (seconds) ఉంచండి తద్వారా నష్టం bound అవుతుంది; DB total ప్లస్ చిన్న gap ఒక view counter కి అంగీకారం.
- **Hot key**: ఒక వైరల్ post మొత్తం traffic ను ఒక Redis key పై కేంద్రీకరిస్తుంది. దానిని `views:{post}:{0..9}` గా shard చేసి read పై sum చేయండి, లేదా hot keys ను ఒక dedicated node కి route చేయండి తద్వారా ఒక post shard ను saturate చేయలేదు.

ఆర్కిటెక్చర్

కాంపోనెంట్‌లు మరియు ఫ్లో

ఇంటర్వ్యూ దృక్కోణం

ట్రేడ్-ఆఫ్‌లు మరియు వైఫల్యం

సంబంధిత ప్రశ్నలు