แคชข้อมูลที่ มีค่าสูงในการสร้าง อ่านบ่อย และเปลี่ยนแปลงน้อย — นั่นคือที่แคชชิ่งให้ผลตอบแทนสูงสุด TTL (time to live) คือการสมดุลระหว่าง ความเสด (ข้อมูลต้องเป็นปัจจุบันแค่ไหน) และ ความอดทนต่อข้อมูลเก่า (ข้อมูลอาจผิดพลาดได้แค่ไหนและนานแค่ไหน)
แคชข้อมูลที่ มีค่าสูงในการสร้าง อ่านบ่อย และเปลี่ยนแปลงน้อย — นั่นคือที่แคชชิ่งให้ผลตอบแทนสูงสุด TTL (time to live) คือการสมดุลระหว่าง ความเสด (ข้อมูลต้องเป็นปัจจุบันแค่ไหน) และ ความอดทนต่อข้อมูลเก่า (ข้อมูลอาจผิดพลาดได้แค่ไหนและนานแค่ไหน)
ผู้ที่มีศักยภาพในการแคชที่ดี ได้คะแนนสูงในทั้งสามหมวดหมู่:
อย่าแคชข้อมูลที่มีค่าน้อยในการคำนวณ การเขียนหนัก หรือข้อมูลลับของผู้ใช้ที่ความเสดต้องแม่นยำ (เช่น ยอดคงเหลือบัญชีในขณะดำเนินการ)
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 กับ การปลดล้างอย่างชัดเจน: write-through หรือ delete-on-write เพื่อให้แคชถูกปลดล้างในขณะที่แหล่งข้อมูลเปลี่ยนแปลง แทนที่จะรอให้หมดอายุ
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
ตรวจสอบ cache hit ratio เพื่อปรับแต่ง TTL: อัตราส่วนต่ำหมายความว่าคุณแคชเกือบไม่มีเลย อัตราส่วนสูงพร้อมกับการบ่นเรื่องข้อมูลเก่าหมายความว่า TTL ยาวเกินไป
การตัดสินใจว่าจะแคชอะไรและ TTL อย่างถูกต้องเป็นหัวใจของการแคชที่มีประสิทธิภาพ แคชสิ่งของผิด และคุณเพิ่มความซับซ้อนโดยไม่ได้ประโยชน์ ตั้ง TTL ยาวเกินไป และคุณให้บริการข้อมูลเก่า สั้นเกินไป และคุณสูญเสียประโยชน์ การใช้ความอดทนต่อข้อมูลเก่าเพื่อเลือก TTL เพิ่มการปลดล้างอย่างชัดเจนเพื่อความถูกต้อง และตรวจสอบ hit ratio ให้วิธีการแคชที่มีหลักการ และวัดได้