Cache invalidation: bayat veri ve stampede sorunu nasıl çözülür

Cache'deki bayat veri (stale data) sorunu, cache ile origin'in iki ayrı kopya olmasından ve senkronizasyon mekanizmalarının (TTL, event-based invalidation, versioning) her zaman bir gecikme penceresi bırakmasından kaynaklanır. Asıl tehlike sadece kullanıcının eski veri görmesi değil; popüler bir key'in TTL'i dolduğunda binlerce isteğin aynı anda cache miss yaşayıp origin'e aynı ağır sorguyu göndermesidir. Bu 'cache stampede' (dogpile, thundering herd) DB connection pool'unu tüketip servisi saniyeler içinde çökertebilir.

Metin dört temel invalidation mekanizmasını (TTL, event-based, versioning, single-flight/request coalescing) ve bunların pratikte nasıl birleştirildiğini ele alıyor: TTL sınırlı bayatlık sağlar, single-flight aynı key için miss olan istekleri tek bir origin çağrısında birleştirir, event-based invalidation ise yazma olduğunda TTL'i erken keser. Go'nun singleflight paketi ve Redis SETNX ile distributed lock örnekleri, bu yaklaşımların gerçek koddaki karşılığını gösteriyor.

Prodüksiyonda sık görülen beş hata örneklendiriliyor: hot key'in TTL'i dolduğunda oluşan stampede, event kaybolduğunda TTL yedeği olmadan sonsuza kadar süren bayatlık, global FLUSHDB sonrası tüm cache'in birden boşalması, L1/L2 katmanlı sistemlerde write-through sonrası tutarsız okuma ve negative caching'de kısa TTL unutulması. Her biri için hem kök neden hem de düzeltme stratejisi (single-flight, XFetch, versioning ile kademeli invalidation, pub/sub ile L1 senkronizasyonu) tarif ediliyor.

Son bölüm, cache hit ratio, origin request rate, staleness distribution ve lock contention gibi izlenmesi gereken metrikleri ve Prometheus/Grafana üzerinden alarm kurulumunu anlatıyor. Genel kural olarak her cache entry'sinin TTL'i olmalı, stampede riski taşıyan her ağır sorgu single-flight ile sarılmalı ve event-based invalidation her zaman TTL güvenlik ağıyla desteklenmeli.