এমন ডেটা ক্যাশ করুন যা উৎপাদনে ব্যয়বহুল, ঘন ঘন পড়া হয়, এবং খুব কমই পরিবর্তিত হয় — এখানেই ক্যাশিং সবচেয়ে বেশি লাভজনক। TTL (সময় জীবন্ত) হল তাজা (ডেটা কতটা বর্তমান হতে হবে) এবং সেতুত্ব সহনশীলতা (এটি কতক্ষণের জন্য কতটা ভুল হতে পারে) এর মধ্যে একটি ভারসাম্য।
একটি ভাল ক্যাশে প্রার্থী তিনটিতেই উচ্চ স্কোর পায়:
সাশ্রয়ী-গণনা, লেখা-ভারী, বা প্রতি-ব্যবহারকারী-গোপনীয় ডেটা ক্যাশ করবেন না যার তাজা সঠিক হতে হবে (যেমন একটি লেনদেনের মুহূর্তে অ্যাকাউন্ট ব্যালেন্স)।
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 কে স্পষ্ট অবৈধতা এর সাথে একত্রিত করুন: লেখা-মাধ্যমে বা মুছে ফেলা-লেখার সময় যাতে ক্যাশ পলায়নের অপেক্ষা না করে মুহূর্তে মুছে দেওয়া হয়।
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 সুর করতে: কম অনুপাত মানে আপনি প্রায় ক্যাশিং করছেন না; উচ্চ অনুপাত সেতুত্ব অভিযোগের সাথে মানে TTLs খুব দীর্ঘ।
কী ক্যাশ করবেন এবং TTL সঠিক পাওয়া কার্যকর ক্যাশিংর মূল বিষয়। ভুল জিনিস ক্যাশ করুন এবং আপনি কোন লাভ ছাড়াই জটিলতা যোগ করুন; TTLs খুব দীর্ঘ সেট করুন এবং আপনি সেতুত্ব ডেটা পরিবেশন করেন; খুব ছোট এবং আপনি সুবিধা হারাবেন। সেতুত্ব সহনশীলতা ব্যবহার করে TTL পছন্দ করতে, সঠিকতার জন্য স্পষ্ট অবৈধতা যোগ করতে, এবং আঘাত অনুপাত দেখতে আপনাকে একটি নীতিগত, পরিমাপযোগ্য ক্যাশিং উপায় দেয়।