Armazene em cache dados que são caros de produzir, lidos frequentemente e que mudam raramente — é aí que o caching compensa mais. O TTL (time to live) é uma trade-off entre frescura (o quão atual os dados devem estar) e tolerância à obsolescência (o quão incorretos podem estar e por quanto tempo).
Um bom candidato para cache obtém alta pontuação nos três aspectos:
Não armazene em cache dados baratos de computar, com muitas escritas, ou dados secretos por usuário cuja frescura deve ser exata (por exemplo, saldos de conta no momento de uma transação).
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
Para correção em dados que mudam de forma imprevisível, combine um TTL com invalidação explícita: write-through ou delete-on-write para que o cache seja limpado no momento exato em que a fonte muda, em vez de esperar pela expiração.
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
Monitore a taxa de acerto do cache para ajustar TTLs: uma taxa baixa significa que você está quase não cacheando; uma taxa alta com reclamações de obsolescência significa que os TTLs são muito longos.
Acertar o que armazenar em cache e o TTL é o núcleo do caching efetivo. Se armazenar as coisas erradas em cache, você adiciona complexidade sem ganho; se definir TTLs muito longos, você serve dados obsoletos; muito curtos e você perde o benefício. Usar a tolerância à obsolescência para escolher TTLs, adicionar invalidação explícita para correção e monitorar a taxa de acerto oferece uma forma principiada e mensurável de fazer cache.