Cache data yang mahal untuk diproduksi, sering dibaca, dan jarang berubah — di situlah caching paling menguntungkan. TTL (time to live) adalah kompromi antara kesegaran (seberapa mutakhir data harus) dan toleransi kedaluwarsa (seberapa salah itu bisa dan berapa lama).
Kandidat cache yang baik mendapat skor tinggi di ketiga hal ini:
Jangan cache data yang murah untuk dihitung, berat penulisan, atau data rahasia per pengguna yang kefreshannya harus tepat (mis. saldo akun pada saat 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 kebenaran pada data yang berubah secara tidak terduga, gabungkan TTL dengan invalidasi eksplisit: write-through atau delete-on-write sehingga cache dihapus pada saat sumber berubah, bukan menunggu kedaluwarsa.
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 menyetel TTL: rasio rendah berarti Anda hampir tidak melakukan caching; rasio tinggi dengan keluhan kedaluwarsa berarti TTL terlalu panjang.
Membuat keputusan yang tepat tentang apa yang di-cache dan TTL adalah inti dari caching yang efektif. Cache hal yang salah dan Anda menambah kompleksitas tanpa keuntungan; atur TTL terlalu panjang dan Anda melayani data yang ketinggalan zaman; terlalu pendek dan Anda kehilangan manfaatnya. Dengan menggunakan toleransi kedaluwarsa untuk memilih TTL, menambahkan invalidasi eksplisit untuk kebenaran, dan memantau rasio hit Anda mendapat cara yang dapat diukur dan prinsip untuk melakukan caching.