Bir isteğin tarayıcıdan veritabanına kadar geçtiği cache katmanları nelerdir? Veri değiştiğinde hepsini nasıl tutarlı tutarsınız?

Bir istek yolunda birden fazla cache katmanından geçer. Her katman latency'yi düşürür ama invalidation (geçersiz kılma) karmaşıklığını artırır. Temel kural: veri değiştiğinde hangi katmanların eski veriyi tuttuğunu ve ne kadar süre tutabileceğini bilmek.

Katmanlar

1. Client state cache: TanStack Query, SWR, Apollo cache. Mutation sonrası invalidateQueries ile yenilenir.
2. Tarayıcı HTTP cache: Cache-Control, ETag ile. Kullanıcıya özel veri için private.
3. Service Worker cache: offline / PWA senaryolarında.
4. CDN / edge cache: s-maxage, stale-while-revalidate; purge API veya cache tag'leri ile temizlenir.
5. Framework cache: Next.js data cache, ISR; revalidatePath / revalidateTag ile.
6. Uygulama cache'i: Redis'te cache-aside (sorgu sonucu, session).
7. Veritabanı: buffer pool, materialized view'lar.

Tutarlılık stratejisi

• Değişmeyen dosyalar: içerik hash'li dosya adları (app.3f9a1c.js) + Cache-Control: public, max-age=31536000, immutable. Invalidation hiç gerekmez; yeni sürüm yeni ad demektir. index.html ise no-cache olmalıdır.
• Herkese açık ama değişen veri (ürün sayfası): CDN'de kısa s-maxage + stale-while-revalidate; ürün güncellenince cache tag ile purge.
• Kullanıcıya özel veri: CDN'de cache'lenmez (private veya no-store); Redis'te kısa TTL.
• Yazma sonrası: önce DB'ye yaz, sonra Redis anahtarını sil (güncellemek yerine silmek yarışları azaltır), sonra CDN tag'ini purge et, client'ta ilgili query'yi invalidate et.

Cache-Control: public, max-age=0, s-maxage=60, stale-while-revalidate=300
ETag: "v42"

// Ürün güncelleme sonrası zincir
await db.product.update({ where: { id }, data });
await redis.del(`product:${id}`);
await cdn.purgeTags([`product-${id}`]);
// client: queryClient.invalidateQueries({ queryKey: ["product", id] })

Tuzaklar

• Kullanıcıya özel yanıtın yanlışlıkla CDN'de cache'lenip başka kullanıcıya gösterilmesi (Set-Cookie olan yanıtlar, eksik Vary başlığı). Bu ciddi bir veri sızıntısıdır.
• Her katmanda uzun TTL: toplam bayatlık süresi katmanların toplamına kadar çıkabilir.
• Cache stampede: popüler anahtarın süresi dolunca binlerce isteğin aynı anda DB'ye gitmesi; lock veya erken yenileme ile çözülür.