وہ ڈیٹا cache کریں جو پیدا کرنے میں مہنگا ہو، بار بار پڑھا جائے، اور شاذ و نادر بدلتا ہو — یہ وہ جگہ ہے جہاں caching سب سے زیادہ فائدہ مند ہے۔ TTL (time to live) تازگی (ڈیٹا کتنا موجودہ ہونا چاہیے) اور پرانا ہونا قابل قبول (یہ کتنے عرصے تک غلط ہو سکتا ہے) کے درمیان ایک توازن ہے۔
ایک اچھا cache امیدوار ان تینوں میں اعلیٰ نمرات حاصل کرتا ہے:
سستے سے compute کرنے والے، write-heavy، یا فی صارف خفیہ ڈیٹا کو cache نہ کریں جس کی تازگی بالکل درست ہونی چاہیے (مثال کے طور پر ایک لین دین کے وقت account balances)۔
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 تاکہ cache اسی لمحے میں ٹوٹ جائے جب source بدلتا ہے، انتظار کرنے کی بجائے۔
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
cache hit ratio دیکھیں TTLs کو ٹیون کرنے کے لیے: کم ratio کا مطلب ہے آپ شاید ہی caching کر رہے ہیں؛ اعلیٰ ratio پرانے ہونے کی شکایتوں کے ساتھ مطلب ہے TTLs بہت لمبے ہیں۔
کیا cache کریں اور TTL صحیح طریقے سے منتخب کرنا موثر caching کا بنیادی ہے۔ غلط چیزوں کو cache کریں اور آپ کوئی فائدہ نہ پاتے ہوئے پیچیدگی شامل کریں؛ TTLs بہت لمبے مقرر کریں اور آپ پرانا ڈیٹا پیش کریں؛ بہت مختصر اور آپ فائدہ کھو دیں۔ staleness tolerance استعمال کرتے ہوئے TTLs منتخب کریں، صحیح کے لیے واضح invalidation شامل کریں، اور hit ratio دیکھیں تو آپ کو caching کا ایک اصولی، قابلِ پیمائش طریقہ ملتا ہے۔