Hãy cache dữ liệu tốn kém để tạo ra, được đọc thường xuyên, và hiếm khi thay đổi — đó là nơi caching mang lại lợi ích nhiều nhất. TTL (time to live) là một đánh đổi giữa độ tươi (dữ liệu phải mới đến mức nào) và mức chịu được stale (nó có thể sai trong bao lâu).
Một ứng viên cache tốt đạt điểm cao ở cả ba:
Đừng cache dữ liệu rẻ để tính, ghi nhiều, hoặc bí mật theo từng user mà độ tươi phải chính xác tuyệt đối (vd. số dư tài khoản tại thời điểm giao dịch).
Mức chịu được stale → TTL:
config / dữ liệu tham chiếu tĩnh → dài (vài giờ đến vài ngày)
danh sách sản phẩm, thân bài viết → trung bình (vài phút)
giá, tồn kho, bảng xếp hạng → ngắn (vài giây)
luôn phải chính xác → đừng cache, hoặc dùng invalidation tường minh
Để đảm bảo tính đúng đắn cho dữ liệu thay đổi khó lường, kết hợp TTL với invalidation tường minh: write-through hoặc delete-on-write để cache bị xóa ngay khi nguồn thay đổi, thay vì chờ hết hạn.
khi update(record):
db.save(record)
cache.delete(key(record)) // invalidate ngay, không phục vụ bản stale cho đến hết TTL
hit ratio = hits / (hits + misses)
cao (>90%) → cache đang làm tốt nhiệm vụ
thấp → TTL quá ngắn, key quá chi tiết, hoặc dữ liệu không cache được
Theo dõi cache hit ratio để tinh chỉnh TTL: tỉ lệ thấp nghĩa là bạn gần như không cache được gì; tỉ lệ cao mà vẫn bị phàn nàn stale nghĩa là TTL quá dài.
Làm đúng việc cache-cái-gì và TTL là cốt lõi của caching hiệu quả. Cache sai thứ thì bạn thêm phức tạp mà chẳng được gì; đặt TTL quá dài thì phục vụ dữ liệu stale; quá ngắn thì mất lợi ích. Dùng mức chịu được stale để chọn TTL, thêm invalidation tường minh cho tính đúng đắn, và theo dõi hit ratio cho bạn một cách cache có nguyên tắc, đo lường được.