آپ 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**: ایک خام counter refreshes کو دوہرا گنتا ہے۔ `SADD seen:{post} {userId}` استعمال کریں اور صرف تب `INCR` کریں جب add نیا ہو؛ بڑے پیمانے پر سستے تخمینی 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 store کریں، صرف نمبر نہیں۔

## انٹرویو کا نقطۂ نظر

انٹرویو لینے والے جانچتے ہیں کہ آپ **counts کے لیے eventual consistency** قبول کرتے ہیں یا نہیں۔ "اچھا" یہ ہے کہ "count کو cache کرو"؛ "عمدہ" یہ ہے کہ *writes* کو buffer کرو — یہ پہچاننا کہ bottleneck ایک hot row پر write contention ہے، read load نہیں۔ وہ trade جانچتے ہیں: کیا ایک تخمینی count قابلِ قبول ہے؟ view counts کے لیے، ہاں — 1,203,428 بمقابلہ 1,203,450 کوئی نہیں دیکھتا۔ جال یہ ہے کہ exact counts کی فکر کریں اور ایک transaction کی طرف بڑھیں، وہی lock دوبارہ لے آئیں جس سے آپ بچ رہے تھے۔

## توازن اور ناکامی

- **درستگی بمقابلہ throughput**: exact counts کو dedup sets چاہئیں (memory-heavy)؛ تخمینی HyperLogLog چھوٹا اور تیز ہے۔ فی feature چنیں — likes exact ہیں، view counts تخمینی ہو سکتے ہیں۔
- **Durability**: Redis in-memory ہے۔ اگر یہ flush سے پہلے مر جائے تو آپ un-flushed delta کھو دیتے ہیں۔ AOF فعال کریں اور flush windows مختصر (سیکنڈوں میں) رکھیں تاکہ نقصان محدود ہو؛ view counter کے لیے DB total جمع ایک چھوٹا gap قابلِ قبول ہے۔
- **Hot key**: ایک viral post تمام traffic کو ایک Redis key پر مرکوز کر دیتی ہے۔ اسے `views:{post}:{0..9}` میں shard کریں اور read پر sum کریں، یا hot keys کو ایک وقف شدہ node پر route کریں تاکہ ایک post shard کو saturate نہ کرے۔

فن تعمیر

اجزاء اور بہاؤ

انٹرویو کا نقطۂ نظر

توازن اور ناکامی

متعلقہ سوالات