Cache डेटा जो उत्पादन गर्न महँगो छ, बारम्बार पढिन्छ, र विरलै परिवर्तन हुन्छ — यही वह जहाँ caching सबैभन्दा बढी लाभदायक हुन्छ। TTL (time to live) freshness (डेटा कति वर्तमान हुनु पर्छ) र staleness tolerance (यो कति गलत हुन सक्छ र कति लामो समय सम्म) को बीचमा एक trade-off हो।
राम्रो cache candidate सबै तीनमा उच्च अंक पाउँछ:
सस्तो-कम्प्यूट, write-heavy, वा per-user-secret डेटा क्यास गर्नुहोस् जसको freshness एकदम सटीक हुनु पर्छ (जस्तै transaction को समयमा खाता balance)।
Staleness tolerance → TTL:
config / static reference data → long (hours to days)
product listings, article body → medium (minutes)
prices, stock, leaderboards → short (seconds)
must always be exact → don't cache, or use explicit invalidation
डेटाको सटिकताको लागि जो अप्रत्याशित रूपमा परिवर्तन हुन्छ, TTL लाई explicit invalidation संग संयोजन गर्नुहोस्: write-through वा delete-on-write ताकि cache expiry को प्रतीक्षा गर्नुको सट्टा स्रोत परिवर्तन हुने क्षणमा busted हुन्छ।
on update(record):
db.save(record)
cache.delete(key(record)) // invalidate now, don't serve stale until TTL
hit ratio = hits / (hits + misses)
high (>90%) → cache is doing its job
low → TTL too short, keys too granular, or data not cacheable
TTLs ट्यून गर्न cache hit ratio पहिले गर्नुहोस्: कम ratio को अर्थ तपाई लगभग क्यासिङ गर्दै हुनुहुन्छ; उच्च ratio साथ stale complaints को अर्थ TTLs अत्यधिक लामो छन्।
के-क्यास गर्ने र TTL सही गर्न प्रभावकारी caching को मूल हो। गलत चीजहरू क्यास गर्नुहोस् र तपाई कोनै लाभ बिना जटिलता थप्नुहुन्छ; TTLs अत्यधिक लामो सेट गर्नुहोस् र तपाई stale डेटा सेवा दिनुहुन्छ; अत्यधिक छोटो र तपाई लाभ हराउनुहुन्छ। Staleness tolerance लाई TTLs छनौट गर्न, सटिकताको लागि explicit invalidation थप्न, र hit ratio पहिरो गर्नु एक सिद्धान्तगत, मापनयोग्य तरिका दिन्छ क्यास गर्न।