ਉਹ ਡੇਟਾ ਕੈਸ਼ ਕਰੋ ਜੋ ਪੈਦਾ ਕਰਨ ਵਿੱਚ ਮਹਿੰਗਾ, ਅਕਸਰ ਪੜ੍ਹਿਆ ਜਾਂਦਾ ਅਤੇ ਬਹੁਤ ਘੱਟ ਬਦਲਦਾ ਹੈ — ਇਹੀ ਉਹ ਥਾਂ ਹੈ ਜਿੱਥੇ caching ਸਭ ਤੋਂ ਵਧੀਆ ਨਤੀਜੇ ਦਿੰਦੀ ਹੈ। TTL (time to live) ਇੱਕ trade-off ਹੈ freshness (ਡੇਟਾ ਕਿੰਨਾ ਮੌਜੂਦਾ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ) ਅਤੇ staleness tolerance (ਇਹ ਕਿੰਨਾ ਗ਼ਲਤ ਹੋ ਸਕਦਾ ਹੈ ਅਤੇ ਕਿੰਨੇ ਸਮੇਂ ਲਈ) ਵਿਚ।
ਇੱਕ ਚੰਗਾ cache candidate ਤਿੰਨਾਂ ਸਭ ਵਿੱਚ ਉੱਚਾ score ਦਿੰਦਾ ਹੈ:
ਸਸਤੇ-ਤੋ-compute, write-heavy, ਜਾਂ per-user-secret ਡੇਟਾ ਜਿਸ ਦੀ freshness exact ਹੋਣੀ ਚਾਹੀਦੀ ਹੈ (ਜਿਵੇਂ ਕਿ ਲੇਨ-ਦੇਣ ਦੇ ਸਮੇਂ account balances) ਨੂੰ cache ਨਾ ਕਰੋ।
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 ਸ੍ਰੋਤ ਦੇ ਤੁਰੰਤ ਬਦਲਣ 'ਤੇ bust ਹੋ, 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
TTLs ਨੂੰ tune ਕਰਨ ਲਈ cache hit ratio ਨੂੰ ਦੇਖੋ: ਘੱਟ ratio ਦਾ ਮਤਲਬ ਹੈ ਕਿ ਤੁਸੀਂ ਬਮੁਸ਼ਕਿਲ cache ਕਰ ਰਹੇ ਹੋ; ਉੱਚਾ ratio stale ਸ਼ਿਕਾਇਤਾਂ ਦੇ ਨਾਲ ਦਾ ਮਤਲਬ ਹੈ ਕਿ TTLs ਬਹੁਤ ਲੰਬੇ ਹਨ।
كya-to-cache ਅਤੇ TTL ਨੂੰ ਸਹੀ ਤਰੀਕੇ ਨਾਲ ਪ੍ਰਾਪਤ ਕਰਨਾ effective caching ਦਾ ਸਾਰ ਹੈ। ਗ਼ਲਤ ਚੀਜ਼ਾਂ cache ਕਰੋ ਅਤੇ ਤੁਸੀਂ ਕੋਈ ਲਾਭ ਛੱਡ ਕੇ ਗੁੰਝਲਦਾਰਤਾ ਜੋੜਦੇ ਹੋ; TTLs ਬਹੁਤ ਲੰਬੇ ਸੈਟ ਕਰੋ ਅਤੇ ਤੁਸੀਂ stale ਡੇਟਾ ਪਰਿਵੇਸ਼ ਕਰਦੇ ਹੋ; ਬਹੁਤ ਛੋਟੇ ਅਤੇ ਤੁਸੀਂ ਲਾਭ ਗੁਆ ਦਿੰਦੇ ਹੋ। Staleness tolerance ਦੀ ਵਰਤੋਂ TTLs ਚੁਣਨ ਲਈ, correctness ਲਈ explicit invalidation ਜੋੜਨਾ, ਅਤੇ hit ratio ਨੂੰ ਦੇਖਣਾ ਤੁਹਾਨੂੰ cache ਕਰਨ ਦਾ ਇੱਕ ਸਿਧਾਂਤਮਿਤ, measurable ਤਰੀਕਾ ਦਿੰਦਾ ਹੈ।