வைரல் 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**: ஒரு raw counter refreshes-ஐ இரட்டை-எண்ணுகிறது. `SADD seen:{post} {userId}` பயன்படுத்தி add புதிதாக இருக்கும்போது மட்டுமே `INCR` செய்யுங்கள்; மிகப் பெரிய அளவில் மலிவான தோராயமான uniques-க்கு **HyperLogLog** (`PFADD`/`PFCOUNT`) பயன்படுத்துங்கள் — சில KB மில்லியன் கணக்கான uniques-ஐ ~2% error-க்குள் மதிப்பிடுகிறது.
- **Batched flusher** delta-ஐ அவ்வப்போது DB-க்கு வடிக்கிறது: `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-ஐ re-warm செய்கிறது. Likes-க்கு per-user state தேவை (*நான்* like செய்தேனா), எனவே ஒரு எண்ணை மட்டுமல்ல, set-ஐச் சேமியுங்கள்.

## நேர்காணல் கண்ணோட்டம்

**counts-க்கு eventual consistency**-ஐ நீங்கள் ஏற்கிறீர்களா என்பதை நேர்காணல் செய்பவர்கள் சோதிக்கிறார்கள். "நல்லது" என்பது "count-ஐ cache செய்"; "சிறந்தது" என்பது *writes*-ஐ buffer செய்வது — bottleneck read load அல்ல, ஒரு hot row மீதான write contention என்பதை உணர்வது. அவர்கள் trade-ஐ ஆராய்கிறார்கள்: ஒரு தோராயமான count ஏற்கத்தக்கதா? view counts-க்கு, ஆம் — 1,203,428 vs 1,203,450-ஐ யாரும் கவனிப்பதில்லை. துல்லியமான counts பற்றிக் கவலைப்பட்டு ஒரு transaction-ஐ நோக்கிச் சென்று, நீங்கள் தவிர்த்த lock-ஐ மீண்டும் அறிமுகப்படுத்துவது தான் பொறி.

## சமரசங்களும் தோல்வியும்

- **Accuracy vs throughput**: துல்லியமான counts-க்கு dedup sets தேவை (memory-heavy); தோராயமான HyperLogLog சிறியது மற்றும் வேகமானது. ஒவ்வொரு feature-க்கும் தேர்ந்தெடுங்கள் — likes துல்லியமானவை, view counts தோராயமாக இருக்கலாம்.
- **Durability**: Redis in-memory. flush-க்கு முன் அது இறந்தால், flush செய்யப்படாத delta-ஐ இழக்கிறீர்கள். AOF-ஐ இயக்கி flush windows-ஐ குறுகியதாக (வினாடிகள்) வைத்து இழப்பை வரம்பிடுங்கள்; DB total மற்றும் ஒரு சிறிய gap ஒரு view counter-க்கு ஏற்கத்தக்கது.
- **Hot key**: ஒரு வைரல் post எல்லா traffic-ஐயும் ஒரே Redis key மீது குவிக்கிறது. அதை `views:{post}:{0..9}` ஆக shard செய்து read-இல் sum செய்யுங்கள், அல்லது hot keys-ஐ ஒரு dedicated node-க்கு route செய்யுங்கள், இதனால் ஒரு post shard-ஐ saturate செய்ய முடியாது.

கட்டமைப்பு

கூறுகளும் ஓட்டமும்

நேர்காணல் கண்ணோட்டம்

சமரசங்களும் தோல்வியும்

தொடர்புடைய கேள்விகள்