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 आहे, त्यामुळे पाहणाऱ्यांना संख्या तत्काळ बदलताना दिसते.
- **likes/unique views साठी Dedup**: raw counter refresh दोनदा मोजतो. `SADD seen:{post} {userId}` वापरा आणि add नवीन असेल तेव्हाच `INCR` करा; प्रचंड 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 पुन्हा warm करते. Likes ना per-user state लागते (मी ते like केले का), म्हणून फक्त संख्या नव्हे तर set साठवा.

## मुलाखतीचा दृष्टिकोन

मुलाखत घेणारे तुम्ही **counts साठी eventual consistency** स्वीकारता का हे तपासतात. "चांगले" म्हणजे "count cache करा"; "उत्तम" म्हणजे *writes* buffer करणे — bottleneck read load नसून hot row वरील write contention आहे हे ओळखणे. ते तडजोड तपासतात: 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 सुरू करा आणि flush windows लहान (सेकंद) ठेवा जेणेकरून तोटा मर्यादित राहील; DB total अधिक एक लहान 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 करू शकणार नाही.

आर्किटेक्चर

घटक आणि प्रवाह

मुलाखतीचा दृष्टिकोन

तडजोडी आणि अपयश

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