viral post का लागि 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 गर्नुहोस्, हरेक केही second मा DB मा batch-flush गर्नुहोस्**, र count Redis बाट पढ्नुहोस्। DB ले टिकाउ total भण्डारण गर्छ, 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 *read* का लागि सत्यको स्रोत हो, त्यसैले दर्शकहरूले संख्या तुरुन्तै चलेको देख्छन्।
- **like/unique view का लागि Dedup**: कच्चा counter ले refresh लाई double-count गर्छ। `SADD seen:{post} {userId}` प्रयोग गर्नुहोस् र add नयाँ हुँदा मात्र `INCR` गर्नुहोस्; ठूलो scale मा सस्तो approximate unique का लागि **HyperLogLog** (`PFADD`/`PFCOUNT`) प्रयोग गर्नुहोस् — केही KB ले ~2% त्रुटि भित्र लाखौं unique अनुमान गर्छ।
- **Batched flusher** ले समय-समयमा delta लाई DB मा drain गर्छ: `UPDATE posts SET views = views + delta`। हरेक 5s वा हरेक N increment मा flush गर्दा दस लाख write मुट्ठीभर मा परिणत हुन्छन् — DB ले cold post र analytics का लागि टिकाउ total राख्छ।
- **Read path** Redis बाट serve गर्छ; cache miss मा यसले DB total पढ्छ र Redis पुनः-warm गर्छ। like लाई प्रति-प्रयोगकर्ता state चाहिन्छ (*मैले* like गरेँ कि), त्यसैले केवल संख्या होइन, set भण्डारण गर्नुहोस्।

## अन्तर्वार्ता दृष्टिकोण

अन्तर्वार्ताकारहरूले तपाईंले **count का लागि eventual consistency** स्वीकार्नुहुन्छ कि भनेर जाँच्छन्। "राम्रो" भनेको "count cache गर"; "उत्कृष्ट" भनेको *write* buffer गर्नु — bottleneck read load होइन, hot row मा write contention हो भनेर चिन्नु। तिनले trade probe गर्छन्: के approximate count स्वीकार्य छ? view count का लागि, हो — 1,203,428 बनाम 1,203,450 कसैले याद गर्दैन। जाल भनेको exact count बारे चिन्ता गर्नु र transaction तिर पुग्नु हो, जसले तपाईंले बच्न खोजेको lock पुनः ल्याउँछ।

## ट्रेड-अफ र failure

- **शुद्धता बनाम throughput**: exact count लाई dedup set (memory-heavy) चाहिन्छ; approximate HyperLogLog सानो र छिटो छ। प्रति feature छान्नुहोस् — like exact हुन्छ, view count approximate हुन सक्छ।
- **Durability**: Redis in-memory छ। flush अघि मर्‍यो भने, तपाईं un-flushed delta गुमाउनुहुन्छ। AOF सक्षम गर्नुहोस् र flush window छोटो (second हरू) राख्नुहोस् ताकि हानि सीमित होस्; view counter का लागि DB total + सानो अन्तर स्वीकार्य छ।
- **Hot key**: viral post ले सबै traffic एउटा Redis key मा केन्द्रित गर्छ। यसलाई `views:{post}:{0..9}` मा shard गर्नुहोस् र read मा sum गर्नुहोस्, वा hot key लाई dedicated node मा route गर्नुहोस् ताकि एउटा post ले shard saturate नगरोस्।

आर्किटेक्चर

कम्पोनेन्ट र प्रवाह

अन्तर्वार्ता दृष्टिकोण

ट्रेड-अफ र failure

सम्बन्धित प्रश्नहरू