TTL (Time to Live / Yaşam Süresi)

TTL (Time to Live / Yaşam Süresi), depolanan bir veri parçasına eklenen bir değerdir — en yaygın olarak bir cache girdisi, ama aynı zamanda DNS kayıtları, oturum token'ları ve object storage yaşam döngüsü kuralları için de geçerlidir — ve o verinin otomatik olarak süresi dolup silinene ya da bayat kabul edilip yenilenmesi gerekene kadar geçerli kalacağı süreyi belirtir. AI/SaaS geliştiricileri için neden önemli: TTL, neredeyse her caching kararında tazelik ile performans/maliyet arasındaki dengeyi ayarlamanın birincil aracıdır. Çok uzun ayarlanmış bir TTL bayat veri sunma riski taşır (kaynak belgesi o zamandan beri değişmiş bir prompt için cache'lenmiş bir LLM yanıtı; artık yanlış olan cache'lenmiş bir ürün fiyatı); çok kısa ayarlanmış bir TTL ise caching'in amacını baştan boşa çıkarır, gereğinden çok daha sık pahalı yeniden hesaplama veya yeniden çekme işlemine zorlar. Her veri türü için doğru TTL'i seçmek, sonradan akla gelen bir ayrıntı değil, gerçekten önemli bir tasarım kararıdır — ve aynı sistemdeki farklı veri parçalarının gerçekte ne sıklıkla değiştiğine bağlı olarak çok farklı TTL değerlerine sahip olması yaygın (ve makul) bir durumdur. Nasıl çalışır: Redis'te TTL doğrudan bir key üzerine ayarlanır (`SETEX key 3600 value`, 3600 saniye sonra süresi dolan bir değer ayarlar, veya mevcut bir key üzerinde `EXPIRE key 3600`), bundan sonra Redis, uygulamadan hiçbir açık silme çağrısı olmadan key'i otomatik olarak kaldırır. HTTP caching ve CDN'lerde TTL, `Cache-Control: max-age=3600` başlıkları aracılığıyla iletilir; bu, tarayıcılara ve CDN edge node'larına origin ile tekrar kontrol etmeden önce cache'lenmiş bir yanıtı ne kadar süre sunabileceklerini söyler. Next.js/Nuxt'ın ISR'ında (Incremental Static Regeneration / Artımlı Statik Yeniden Oluşturma) bir sayfanın revalidation aralığı, aslında render edilmiş sayfa üzerinde bir TTL'dir. TTL seçimi gerçek bir denge (trade-off) matrisi içerir: değişkenliği yüksek veri (bir hisse fiyatı, canlı stok sayısı) çok kısa bir TTL'e veya bunun yerine olay tabanlı (event-driven) invalidation'a ihtiyaç duyar; nadiren değişen veri (bir sözlük terimi tanımı, tamamlanmış bir AI üretimi) güvenle çok uzun, bazen günlerle ölçülen bir TTL kullanabilir. Somut örnek: bir AI SaaS ürünü, LLM tarafından üretilen ürün açıklamalarını 24 saatlik bir TTL ile cache'ler — her sayfa görüntülemesinde aynı açıklamayı yeniden üretmeyi (ve yeniden ödeme yapmayı) önlemeye yetecek kadar uzun, ancak bir satıcının fiyat veya özellik güncellemesinin, her olası kaynak veri değişikliğine bağlı açık bir cache-invalidation mantığı kurmaya gerek kalmadan bir gün içinde AI tarafından üretilen metne yansımasını sağlayacak kadar kısa. Bu yalnızca-TTL yaklaşımı bilinçli bir sadelik ödünleşimidir: ekip, ürünün altında yatan verisini değiştirebilecek her kod yolunda olay tabanlı cache invalidation kurup bakımını yapmak zorunda kalmamak karşılığında 24 saate kadar bayatlığı kabul eder — near-real-time doğruluğun katı bir gereklilik olmadığı bir özellik için makul bir bahis.