நிமிடத்திற்கு மில்லியன் கணக்கான req-இல் DB load-ஐக் குறைக்க எப்படி cache செய்வீர்கள்?

Question

IT Interview Practice · Accepted Answer

DB-க்கு முன்னால் ஒரு **cache-aside** layer (Redis/Memcached) வைக்கவும், இதனால் reads memory-ஐ அடைகின்றன, entries-க்கு ஒரு **TTL** கொடுங்கள் மற்றும் **write-இல் invalidate** செய்யுங்கள், ஒரு cold key DB மீது ஒரு thundering herd-ஐ கட்டவிழ்க்காதபடி **stampede protection** சேர்க்கவும், மேலும் ஒரு popular key ஒரு single node-ஐ உருகச் செய்யாதபடி **hot keys**-ஐ replicas முழுவதும் பரப்புங்கள்.

```text
                 ┌── hit ──▶ return value
request ──▶ cache│
                 └── miss ─▶ lock ─▶ DB read ─▶ set(TTL) ─▶ return
                              │
                    (only ONE miss populates; others wait)
DB writes ──▶ invalidate/update key
```

## Cache-aside vs read-through

**cache-aside**-இல் app cache-ஐச் சரிபார்க்கிறது; ஒரு miss-இல் அது DB-ஐப் படித்து cache-ஐ தானே populate செய்கிறது. **read-through**-இல் cache library அதை உங்களுக்குச் செய்கிறது. எப்படியிருந்தாலும் இலக்கு ஒன்றே: ஒரு 5ms DB query-ஐ ஒரு 0.2ms memory lookup ஆக மாற்றுவது, எனவே 95% hit rate கொண்ட ஒரு cache DB read traffic-ஐ **20×** குறைக்கிறது. நிமிடத்திற்கு மில்லியன் கணக்கான req-இல் DB வெறுமனே ஒவ்வொரு read-ஐயும் serve செய்ய முடியாது — cache தான் எண்களை வேலை செய்ய வைக்கிறது.

## TTL + invalidation

cache-ஐ fresh-ஆக வைக்க இரண்டு வழிகள், மேலும் நீங்கள் வழக்கமாக இரண்டும் தேவை. **TTL** staleness-ஐ bound செய்கிறது — ஒரு entry N வினாடிகளுக்குப் பிறகு expire ஆகிறது, எனவே தவறான data தானாகச் சரியாகிறது. **Explicit invalidation** TTL-க்காகக் காத்திருக்க முடியாத correctness-க்காக write-இல் key-ஐ delete/update செய்கிறது. classic bug என்னவென்றால் invalidation இல்லாமல் cache செய்து நிமிடங்களுக்கு stale data-ஐ serve செய்வது; நுட்பமானது ஒரே write-இல் invalidate *மற்றும்* set செய்வது, இது race ஆகிறது.

## Stampede protection & hot keys

- **Stampede (thundering herd):** ஒரு hot key expire ஆகும்போது, ஆயிரக்கணக்கான concurrent misses அனைத்தும் ஒரே நேரத்தில் DB-ஐ அடைந்து அதைக் கவிழ்க்கலாம். ஒரு **per-key lock/single-flight** (ஒரு request மட்டும் recompute செய்கிறது, மற்றவை காத்திருக்கின்றன) அல்லது expiry-க்கு முன் **early/probabilistic refresh** உடன் சரிசெய்யுங்கள்.
- **Hot keys:** ஒரு key (ஒரு celebrity-இன் profile) ஒரே Redis node-இன் CPU/network-ஐ saturate செய்யலாம். அதைப் பரப்புங்கள் — key-ஐ nodes முழுவதும் replicate செய்யுங்கள், அல்லது hottest items-க்கு Redis-க்கு முன்னால் ஒரு சிறிய local in-process cache சேர்க்கவும்.

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

"Redis சேர்" என்பதற்கு அப்பால் நீங்கள் யோசிப்பதை நேர்காணல் செய்பவர் பார்க்க விரும்புகிறார். நல்லது: TTL உடன் cache-aside. சிறந்தது: நீங்கள் **stampede protection, invalidation strategy, hot-key handling, மற்றும் ஒரு cache outage-இல் என்ன நடக்கிறது** என்று குறிப்பிடுகிறீர்கள். cache எப்போதும் up என்று கருதுவது தான் பொறி — Redis இறந்து ஒவ்வொரு miss-ம் DB-க்கு விழுந்தால், DB-ஐயும் கீழே இறக்கும் ஒரு **cache-avalanche** பெறுகிறீர்கள்.

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

- **Staleness vs load:** குறுகிய TTL = fresh ஆனால் அதிக misses; நீண்ட TTL = குறைவான misses ஆனால் staler. data-க்கு ஏற்ப tune செய்யுங்கள்.
- **Cache avalanche:** பல keys ஒன்றாக expire ஆவது (அதே TTL) ஒரு load spike ஏற்படுத்துகிறது — TTLs-ஐ **jitter** செய்யுங்கள்.
- **Consistency:** cache மற்றும் DB diverge ஆகலாம்; money-critical reads-க்கு, DB-ஐப் படியுங்கள் அல்லது write-through பயன்படுத்துங்கள்.
- **Memory eviction:** அழுத்தத்தின் கீழ் Redis policy மூலம் evict செய்கிறது (LRU/LFU); ஒரு தவறான policy உங்கள் hot set-ஐ அமைதியாக drop செய்கிறது.

Cache-aside vs read-through

TTL + invalidation

Stampede protection & hot keys

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

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

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