डेटा को कैश करें जो उत्पादन के लिए महंगा है, अक्सर पढ़ा जाता है, और शायद ही कभी बदलता है — यह वह जगह है जहां कैशिंग सबसे अधिक लाभ देती है। TTL (time to live) ताजगी (डेटा कितना वर्तमान होना चाहिए) और पुरानेपन की सहनशीलता (यह कितना गलत हो सकता है और कितने समय तक) के बीच एक व्यापार है।
एक अच्छा कैश उम्मीदवार सभी तीनों पर उच्च स्कोर करता है:
सस्ते-कंप्यूट, लेखन-भारी, या प्रति-उपयोगकर्ता-गुप्त डेटा को कैश न करें जिसकी ताजगी सटीक होनी चाहिए (उदा., लेनदेन के समय खाता शेष)।
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 को स्पष्ट invalidation के साथ मिलाएं: write-through या delete-on-write ताकि कैश तुरंत साफ हो जाए जब स्रोत बदलता है, expiry के लिए प्रतीक्षा करने के बजाय।
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
TTL को ट्यून करने के लिए cache hit ratio को देखें: कम अनुपात का मतलब है कि आप बस कैशिंग नहीं कर रहे हैं; पुराने होने की शिकायतों के साथ उच्च अनुपात का मतलब है कि TTL बहुत लंबे हैं।
क्या कैश करें और TTL सही करना प्रभावी कैशिंग का मूल है। गलत चीजों को कैश करें और आप लाभ के बिना जटिलता जोड़ते हैं; TTL बहुत लंबे सेट करें और आप पुराना डेटा सेवा करते हैं; बहुत कम और आप लाभ खो देते हैं। पुरानेपन की सहनशीलता का उपयोग करके TTL चुनकर, सही करने के लिए स्पष्ट invalidation जोड़कर, और हिट अनुपात को देखकर आपको कैश करने का एक सिद्धांत, मापने योग्य तरीका मिलता है।