ਤੁਸੀਂ 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 store ਕਰਦਾ ਹੈ, 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 ਨੂੰ ਜਜ਼ਬ ਕਰਦਾ ਹੈ। ਇੱਕ single `INCR views:{post}` atomic ਹੈ ਅਤੇ ਇੱਕ key ਉੱਤੇ 100k+ ops/s ਸੰਭਾਲਦਾ ਹੈ — ਇੱਕ Postgres row ਤੋਂ ਕਈ ਗੁਣਾ ਵੱਧ। ਇਹ counter *reads* ਲਈ source of truth ਹੈ, ਇਸ ਲਈ viewers ਨੂੰ number ਤੁਰੰਤ ਬਦਲਦਾ ਦਿਸਦਾ ਹੈ।
- **Dedup for likes/unique views**: ਇੱਕ raw counter refreshes ਨੂੰ double-count ਕਰਦਾ ਹੈ। `SADD seen:{post} {userId}` ਵਰਤੋ ਅਤੇ ਸਿਰਫ਼ ਤਦ `INCR` ਕਰੋ ਜਦੋਂ add ਨਵਾਂ ਹੋਵੇ; ਵੱਡੇ scale ਉੱਤੇ ਸਸਤੇ approximate uniques ਲਈ **HyperLogLog** (`PFADD`/`PFCOUNT`) ਵਰਤੋ — ਕੁਝ KB ~2% error ਦੇ ਅੰਦਰ ਲੱਖਾਂ uniques ਦਾ ਅੰਦਾਜ਼ਾ ਲਾਉਂਦੇ ਹਨ।
- **Batched flusher** periodically 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 ਕਰੋ, ਸਿਰਫ਼ ਇੱਕ number ਨਹੀਂ।

## ਇੰਟਰਵਿਊ ਦਾ ਨਜ਼ਰੀਆ

ਇੰਟਰਵਿਊਅਰ ਪਰਖਦੇ ਹਨ ਕਿ ਕੀ ਤੁਸੀਂ **counts ਲਈ eventual consistency** ਸਵੀਕਾਰ ਕਰਦੇ ਹੋ। "ਵਧੀਆ" ਹੈ "count ਨੂੰ cache ਕਰੋ"; "ਸ਼ਾਨਦਾਰ" ਹੈ *writes* ਨੂੰ buffer ਕਰਨਾ — ਇਹ ਪਛਾਣਨਾ ਕਿ bottleneck ਇੱਕ hot row ਉੱਤੇ write contention ਹੈ, read load ਨਹੀਂ। ਉਹ 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 ਛੋਟੇ (ਸਕਿੰਟ) ਰੱਖੋ ਤਾਂ ਜੋ ਨੁਕਸਾਨ ਸੀਮਤ ਰਹੇ; 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 ਨਾ ਕਰ ਸਕੇ।

ਆਰਕੀਟੈਕਚਰ

ਕੰਪੋਨੈਂਟ ਅਤੇ ਫਲੋ

ਇੰਟਰਵਿਊ ਦਾ ਨਜ਼ਰੀਆ

ਟ੍ਰੇਡ-ਆਫ ਅਤੇ ਫੇਲੀਅਰ

ਸੰਬੰਧਿਤ ਸਵਾਲ