Mobil Geliştirmede Önbellek Geçersiz Kılma: Stratejiler ve Mekanizmalar

Önbellek geçersiz kılma nedir?

Önbellek geçersiz kılma, veri kaynağının mevcut durumuyla artık eşleşmeyen önbelleğe alınmış girişleri geçersiz kılma veya güncelleme sürecidir. Tüm önbelleği manuel olarak temizlemenin aksine, geçersiz kılma seçici olarak çalışır: yalnızca ilgisi sorgulanan veriler.

Önbellek, hızlı erişim için veri kopyalarını saklar. Zamanla, veritabanındaki veya sunucudaki orijinal veriler değişebilir — örneğin, bir kullanıcı profilini güncelledi veya akışta yeni bir gönderi göründü. Önbellek geçersiz kılınmazsa, uygulama eski bilgileri gösterir ve bu da mobil uygulamalarda işlem hatalarına, yanlış görüntülemeye ve güven kaybına yol açar.

Herhangi bir geçersiz kılmanın ana zorluğu, bilinen deyiştir: “There are only two hard things in Computer Science: cache invalidation and naming things”. Karmaşıklık, önbelleğe açıkça bildirilmediği sürece kaynağın ne zaman değiştiğini bilmemesi gerçeğinde yatar.

Martin Kleppmann'a göre (“Designing Data-Intensive Applications” (O'Reilly, 2017) kitabının yazarı), doğru geçersiz kılma, değişikliklerin merkezi bildirimini veya her okumada ilgiliyi kontrol eden bir mekanizmayı gerektirir — performans ve tutarlılık arasında bir ödünleşim.

data class CacheEntryT(
    val data: T,
    val expiresAt: Long,
    val version: Int = 0
)

fun CacheT.isValid(key: String): Boolean =
    get(key)?.let { it.expiresAt > currentTimeMillis() && it.version == currentVersion(key) } ?: false

Bu kod basit bir yaklaşım gösterir: TTL süresi dolmamışsa ve sürüm kaynaktaki mevcut sürümle eşleşiyorsa önbellek girişi geçerli kabul edilir. Sürümleme mekanizması, eski verilerin görüntülenmesini önlemenin güvenilir yollarından biridir.

Mobil uygulamalarda neden geçersiz kılma gerekir

Veri tazeliği, çoğu mobil uygulama için temel bir gerekliliktir: sosyal ağlar, mesajlaşma uygulamaları, bankacılık hizmetleri, e-ticaret platformları. Yanlış hesap bakiyesi veya eski mesajlar gören bir kullanıcı, uygulamaya olan güvenini kaybeder.

Kullanıcı deneyiminin yanı sıra, geçersiz kılma trafik ve pil tasarrufu sağlar. Tüm verileri periyodik olarak yeniden yüklemek yerine, bir mobil uygulama yalnızca değiştirilen girişleri geçersiz kılabilir ve bunları seçici olarak yükleyebilir. Meta Engineering (2024)'e göre, Facebook Lite'da artımlı geçersiz kılmanın uygulanması, içerik tazeliğini kaybetmeden trafik tüketimini %35 azaltmıştır.

Bir diğer önemli husus da işlem tutarlılığıdır. Alışveriş sepeti veya rezervasyon sistemi olan uygulamalarda, eski önbellek kullanımı çift fatura veya veri çakışmalarına yol açabilir. Kritik işlemlerden sonra geçersiz kılma, bir sonraki isteğin taze veri okumasını garanti eder.

Önbellek geçersiz kılmanın ana stratejileri

TTL (Time-To-Live)

TTL en basit stratejidir; her önbellek girişine sabit bir yaşam süresi verilir. TTL süresi dolduğunda, veriler eski kabul edilir ve bir sonraki okumada kaldırılır. TTL, bir programa göre güncellenen veriler için idealdir — örneğin, hava durumu veya döviz kurları. Dezavantajı: veriler TTL aralığı içinde güncel olmayabilir.

Write-Through

Write-Through stratejisinde, her veri değişikliği önbellekten geçer: yazma işlemi aynı anda hem önbelleğe hem de kaynağa gerçekleştirilir. Bu, önbelleğin her zaman güncel sürümü içermesini sağlar. Dezavantajı, kaynak onaylayana kadar işlem tamamlanmadığı için artan yazma gecikmesidir. Write-Through, tutarlılık açısından kritik veriler için uygundur: hesap bakiyesi, sipariş durumu.

Write-Behind (Write-Back)

Write-Behind eşzamansız yazmadır: veriler hemen önbelleğe gider ve daha sonra ayrı bir işlemle kaynağa yazılır. Bu, yüksek yazma performansı sağlar ancak senkronizasyondan önce bir arıza durumunda veri kaybı riski taşır. Mobil uygulamalarda Write-Behind genellikle analitik, günlükler ve kritik olmayan kullanıcı eylemleri için kullanılır.

Write-Invalidate

Write-Invalidate — veri değiştiğinde önbelleği güncellemek yerine, ilgili girişi basitçe kaldırır (geçersiz kılar). Sonraki okuma bir önbellek hatası algılayacak ve kaynaktan taze veri yükleyecektir. Bu strateji uygulaması basittir ve okuma isteklerinin yazma isteklerinden önemli ölçüde fazla olduğu durumlarda iyi çalışır.

Strateji seçimi, belirli bir senaryo için neyin daha önemli olduğuna bağlıdır: yanıt hızı, tutarlılık veya kaynak tasarrufu. Karma yaklaşımlar — örneğin, push bildirimi alındığında TTL ile Write-Invalidate — optimal bir denge sağlar.

Farklı önbellek seviyelerinde geçersiz kılma nasıl çalışır

HTTP önbelleği, istemci tarafındaki ilk seviyedir. Tarayıcı veya mobil uygulama, Cache-Control ve ETag başlıklarıyla sunucu yanıtlarını saklar. Geçersiz kılma, 304 Not Modified yanıtı alındığında veya max-age süresi dolduğunda gerçekleşir. ETag, istemcinin tam yanıtı indirmeden kaynağın güncelliğini kontrol etmesine olanak tanır.

Uygulama önbelleği, kod tarafından yönetilen ikinci seviyedir: bellek içi önbellekler (LRU, Android'de LruCache) veya disk önbellekleri (SQLite, Room, Realm). Buradaki geçersiz kılma geliştirici tarafından kontrol edilir. Android Developers (2025)'e göre, Flow ve tetikleyici tabanlı geçersiz kılma ile Room'un doğru kullanımı UI yeniden çizimlerini %40 azaltır.

Sunucu önbelleği üçüncü seviyedir: Redis, Memcached, CDN. Bu seviyede, geçersiz kılma TTL, DEL/PURGE komutları veya mesaj brokerları (RabbitMQ, Kafka) aracılığıyla yapılır. CDN geçersiz kılma ayrı bir zorluktur: CDN'nin dağıtık yapısı nedeniyle, bir temizleme komutunun küresel olarak yayılması dakikalar sürebilir. Cloudflare'e (2024) göre, Purge by URL ile geçersiz kılma, küresel yayılma için ortalama 5–15 saniye sürer.

Tüm seviyelerde geçersiz kılmayı koordine etmek için merkezi bir önbellek hizmeti veya olay brokerı kullanılır. Veriler değiştiğinde, kaynak bir olay yayınlar ve her seviye belirli anahtarları geçersiz kılma komutu alır. Bu, bir seviyenin verileri zaten güncellemişken diğerinin eski sürümü sunmaya devam etmesi durumunu önler.

Önbellek geçersiz kılmada yaygın hatalar

Çok uzun TTL en yaygın hatadır. Geliştiriciler TTL'yi marjlı ayarlar ve bu da kullanıcıların saatlerce veya günlerce eski veri görmesine neden olur. Çözüm: kısa TTL (1–5 dakika) ile başlayın ve yalnızca gerçek ihtiyacı ölçtükten sonra artırın.

Tek bir değişiklikte tüm önbelleği geçersiz kılma, mikrosit mimarisinde tipik bir sorundur. Bir kullanıcı avatarını günceller ve önbellek herkes için geçersiz kılınır. Çok sayıda kullanıcı olduğunda bu, Cache Stampede'e — kaynağa yönelik bir istek seli — neden olur. Çözüm: paylaşılan önbelleği değil, yalnızca belirli kullanıcının anahtarını geçersiz kılın.

Yazma hatalarında geçersiz kılma eksikliği — kaynağa yazma başarısız olursa ancak önbellek zaten güncellenmişse, uygulama tutarsız bir duruma düşer. Çözüm: iki aşamalı geçersiz kılma — önce önbelleği temizleyin, sonra kaynağa yazın ve hata durumunda geçersiz kılmayı geri alın.

Dağıtık yapıyı göz ardı etme — küme ortamında, bir düğümdeki geçersiz kılma diğer düğümlerin komutu aldığı anlamına gelmez. Olay brokerı olmadan, bazı sunucular eski veri sunmaya devam edecektir. Redis Pub/Sub veya Apache Kafka, geçersiz kılma olaylarını yayınlayarak bu sorunu çözer.

Geçersiz kılma stratejisi nasıl seçilir

Güncellik gereksinimlerini belirleyin — verilerin “hemen şimdi” güncel olması ne kadar kritik. Haber akışı için 1–2 dakikalık gecikme kabul edilebilir (TTL). Hesap bakiyesi için gecikme kabul edilemez (Write-Through).

Değişiklik sıklığını değerlendirin — günde bir kez güncellenen veriler (ürün kataloğu, şehir rehberi) TTL ile iyi çalışır. Saniyede onlarca kez değişen veriler (çevrimiçi durumlar, döviz kurları), WebSocket veya Firebase Cloud Messaging aracılığıyla push geçersiz kılma gerektirir.

Kaynak okuma maliyetini göz önünde bulundurun — kaynak 10 tabloda pahalı bir SQL sorgusu veya sınırlamaları olan harici bir API ise, uzun TTL ile agresif önbellekleme kullanın ancak eski verileri push geçersiz kılma ile telafi edin. Okuma ucuzsa (bellek içi arama), kısa TTL ve Write-Invalidate kullanın.

Google I/O (2025)'e göre, mobil uygulamalar için tipik desen Stale-While-Revalidate şeklindedir: kullanıcı önbelleğe alınmış verileri hemen görürken uygulama arka planda güncelliğini kontrol eder ve günceller. Bu, ödün vermeden yanıt hızı ve güncellik sağlar. stale-while-revalidate yönergesi içeren Cache-Control HTTP başlığı, Android 10 ve iOS 13'ten itibaren desteklenir.