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

## कंपोनेंट्स और फ्लो

- **Redis INCR** write storm को सोख लेता है। एक अकेला `INCR views:{post}` atomic है और एक key पर 100k+ ops/s संभालता है — Postgres row से कई गुना आगे। यह counter *reads* का source of truth है, इसलिए viewers को संख्या तुरंत बढ़ती दिखती है।
- **Likes/unique views के लिए dedup**: एक कच्चा counter refreshes को double-count करता है। `SADD seen:{post} {userId}` इस्तेमाल करें और केवल तब `INCR` करें जब add नया हो; भारी scale पर सस्ते approximate uniques के लिए **HyperLogLog** (`PFADD`/`PFCOUNT`) इस्तेमाल करें — कुछ KB लाखों uniques को ~2% error के भीतर अनुमानित करते हैं।
- **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 को फिर से गर्म करता है। Likes को per-user state चाहिए (क्या *मैंने* इसे like किया), इसलिए set स्टोर करें, केवल संख्या नहीं।

## इंटरव्यू का नज़रिया

Interviewers परखते हैं कि क्या आप **counts के लिए eventual consistency** स्वीकार करते हैं। "अच्छा" है "count cache करें"; "बढ़िया" है *writes* को buffer करना — यह पहचानना कि bottleneck एक hot row पर write contention है, read load नहीं। वे trade परखते हैं: क्या approximate count स्वीकार्य है? view counts के लिए, हां — 1,203,428 बनाम 1,203,450 कोई नहीं देखता। जाल है exact counts की चिंता करना और transaction की ओर बढ़ना, उसी lock को फिर से लाना जिससे आप बच रहे थे।

## ट्रेड-ऑफ़ और failure

- **Accuracy बनाम throughput**: exact counts को dedup sets चाहिए (memory-heavy); approximate HyperLogLog छोटा और तेज़ है। प्रति feature चुनें — likes exact हैं, view counts approximate हो सकते हैं।
- **Durability**: Redis in-memory है। अगर यह flush से पहले मर जाए, तो आप un-flushed delta खो देते हैं। AOF सक्षम करें और flush windows छोटी (सेकंड) रखें ताकि loss सीमित रहे; DB total plus एक छोटा gap एक view counter के लिए स्वीकार्य है।
- **Hot key**: एक viral post सारा traffic एक Redis key पर केंद्रित कर देता है। इसे `views:{post}:{0..9}` में shard करें और read पर sum करें, या hot keys को एक dedicated node पर route करें ताकि एक post shard को saturate न कर सके।

आर्किटेक्चर

कंपोनेंट्स और फ्लो

इंटरव्यू का नज़रिया

ट्रेड-ऑफ़ और failure

संबंधित प्रश्न