Cache data yang mahal untuk dihasilkan, kerap dibaca, dan jarang berubah — di situlah caching paling berbaloi. TTL (time to live) ialah pertukaran (trade-off) antara kesegaran (sejauh mana data perlu terkini) dan toleransi terhadap data lapuk (sejauh mana ia boleh salah untuk berapa lama).
Calon cache yang baik mendapat markah tinggi pada ketiga-tiganya:
Jangan cache data yang murah untuk dikira, banyak tulisan (write-heavy), atau rahsia setiap pengguna yang kesegarannya mesti tepat (cth. baki akaun pada saat sesuatu transaksi).
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
Untuk ketepatan pada data yang berubah secara tidak dapat diramal, gabungkan TTL dengan pembatalan eksplisit (explicit invalidation): write-through atau delete-on-write supaya cache dibatalkan pada saat sumber berubah, bukannya menunggu tamat tempoh.
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
Perhatikan cache hit ratio untuk menala TTL: nisbah yang rendah bermakna anda hampir tidak men-cache; nisbah yang tinggi dengan aduan data lapuk bermakna TTL terlalu panjang.
Mendapatkan apa-yang-di-cache dan TTL dengan betul ialah teras caching yang berkesan. Cache perkara yang salah dan anda menambah kerumitan tanpa faedah; tetapkan TTL terlalu panjang dan anda menyajikan data lapuk; terlalu pendek dan anda hilang manfaatnya. Menggunakan toleransi kelapukan untuk memilih TTL, menambah pembatalan eksplisit untuk ketepatan, dan memerhati hit ratio memberi anda cara yang berprinsip dan boleh diukur untuk men-cache.