WEB / WEB-19.01

Application cache ve invalidation

İlk public note okumasında store’a gidilir, sonraki okumada cache kopyası kullanılır. Miss, hata ve eski revision durumlarını ayrı izle.

CORE · RED · BLUE · ARTIFACT · PRACTICE

Hareket olmadan bütün senaryoları oku

Miss, sonra hit

Public note isteniyor
Application, public Tea note’u okumak ister. Bu örnekte application, cache kopyası ve asıl note store aynı process içinde yerel bileşenlerdir; henüz store read veya cache fill yapılmadı.
Uygulama
Public note okuması
Yerel cache
Cache sonucu yok
Asıl store
Asıl kayıt: Tea note / version=1
Sonuç kararı
Sonuç yok
Cache’te kayıt yok
Local entry bulunmaz. Bu miss, note’un asıl store’da da bulunmadığını söylemez.
Uygulama
Public note okuması
Yerel cache
Miss / cache kopyası yok
Asıl store
Asıl kayıt: Tea note / version=1
Sonuç kararı
Sonuç yok
Store’dan oku
Store title ve version=1 döndürür; readCount=1 olur. Sayaç okuma sayısını gösterir, latency ölçmez.
Uygulama
Public note okuması
Yerel cache
Miss / cache kopyası yok
Asıl store
Tea note / version=1 / readCount=1
Sonuç kararı
Sonuç yok
Cache kopyası oluştur
Public note’un ayrı kopyası cache’e konur. Application’a verilen object sonradan değişse bile saklanan cache kopyası değişmez; applicationMutationChangesCache=false bunu gözler.
Uygulama
Public note okuması
Yerel cache
Cache kopyası: Tea note / version=1
Asıl store
Tea note / version=1 / readCount=1
Sonuç kararı
Sonuç yok
İlk sonuç hazır
İlk miss sonrasında store’dan okunan note kullanılır. Bu adım uygulama sonucudur; browser’a HTTP teslimi gösterilmez.
Uygulama
Public note okuması
Yerel cache
Cache kopyası: Tea note / version=1
Asıl store
Tea note / version=1 / readCount=1
Sonuç kararı
İlk sonuç: Tea note / version=1
Sonraki okumada hit
Sonraki read cache kopyasını bulur; store readCount=1 kalır. Cache hit, en yeni store state’ini bildiğimizi tek başına garanti etmez.
Uygulama
Public note okuması
Yerel cache
Hit: Tea note / version=1
Asıl store
Tea note / version=1 / readCount=1
Sonuç kararı
İlk sonuç: Tea note / version=1
Kopya yeniden kullanıldı
Public note sonucu cache hit üzerinden sağlanır. Sahne hangi kopyanın kullanıldığını gösterir; production performansı ölçmez.
Uygulama
Public note okuması
Yerel cache
Hit: Tea note / version=1
Asıl store
Tea note / version=1 / readCount=1
Sonuç kararı
Yeniden kullanılan: Tea note / version=1

Late old fill

Public note isteniyor
Uygulama public note okumak ister. Local cache bir kopyadır; doğru verinin sorumlusu ayrı store’dur.
Uygulama
Public note okuması
Yerel cache
Cache sonucu yok
Asıl store
Asıl kayıt: Tea note / version=1
Sonuç kararı
Sonuç yok
Eski aday bekliyor
Reader version=1 adayını hazırlamıştır. Cache’e yazma henüz tamamlanmamıştır.
Uygulama
Fill bekliyor: Tea note / v1
Yerel cache
Cache sonucu yok
Asıl store
Asıl kayıt: Tea note / version=1
Sonuç kararı
Sonuç yok
Store’da yeni revision
Store Coffee note ve version=2 kaydını commit eder. Bekleyen eski aday kendiliğinden güncellenmez.
Uygulama
Fill bekliyor: Tea note / v1
Yerel cache
Cache sonucu yok
Asıl store
Asıl kayıt: Coffee note / version=2
Sonuç kararı
Sonuç yok
Eski kopyayı geçersiz kıl
Current revision=2 bilgisiyle cache entry geçersiz kılınır. Başka process’lerdeki kopyaların da eşzamanlı güncellendiği varsayılmaz.
Uygulama
Fill bekliyor: Tea note / v1
Yerel cache
Cache boş / bilinen revision=2
Asıl store
Asıl kayıt: Coffee note / version=2
Sonuç kararı
Sonuç yok
Eski aday fill sınırında
Version=1 adayı cache’e yazılmak üzeredir; store’un current revision değeri artık 2’dir.
Uygulama
Candidate=1 / current=2
Yerel cache
Cache boş / bilinen revision=2
Asıl store
Asıl kayıt: Coffee note / version=2
Sonuç kararı
Sonuç yok
Eski fill reddedildi
Aynı karar sınırındaki revision kontrolü eşleşmez; fill reddedilir ve cache boş kalır. Bu yerel kontrol distributed synchronization garantisi değildir.
Uygulama
Candidate=1 / current=2
Yerel cache
Candidate=1 reddedildi / cache boş
Asıl store
Asıl kayıt: Coffee note / version=2
Sonuç kararı
Sonuç yok
Current veriyi yeniden oku
Yeni store read version=2 alır. Reddedilen eski aday yerine committed veri seçilir.
Uygulama
Candidate=1 / current=2
Yerel cache
Candidate=1 reddedildi / cache boş
Asıl store
Current sonuç: Coffee note / version=2
Sonuç kararı
Sonuç yok
Güncel sonuç hazır
Uygulama version=2 sonucunu kullanır. Sonuç bu örnekteki yerel cache ve store kararlarına dayanır.
Uygulama
Candidate=1 / current=2
Yerel cache
Candidate=1 reddedildi / cache boş
Asıl store
Current sonuç: Coffee note / version=2
Sonuç kararı
Coffee note / version=2

Cache error

Public note isteniyor
Uygulama public note okumak ister. Local cache bir kopyadır; doğru verinin sorumlusu ayrı store’dur.
Uygulama
Public note okuması
Yerel cache
Cache sonucu yok
Asıl store
Asıl kayıt: Tea note / version=1
Sonuç kararı
Sonuç yok
Cache kullanılamıyor
Cache hata verir. Bu sonuç miss değildir; store’da note bulunmadığı anlamına da gelmez.
Uygulama
Public note okuması
Yerel cache
Hata / cache sonucu yok
Asıl store
Asıl kayıt: Tea note / version=1
Sonuç kararı
Sonuç yok
Tanımlı fallback uygulanıyor
Public read policy’si store’dan doğrudan okumayı seçer. Her operation için aynı fallback’in uygun olduğu varsayılmaz.
Uygulama
Public note okuması
Yerel cache
Hata / cache sonucu yok
Asıl store
Fallback: Tea note / version=1
Sonuç kararı
Sonuç yok
Cache’e yazılamadı
Cache hâlâ kullanılamadığı için yeni entry yazıldığı söylenmez. Store’dan alınan sonuç kopyası korunur.
Uygulama
Public note okuması
Yerel cache
Kullanılamıyor / entry yazılmadı
Asıl store
Fallback: Tea note / version=1
Sonuç kararı
Sonuç yok
Store sonucu kullanıldı
Uygulama store’dan gelen public sonucu kullanır. Store da hata verseydi bunu boş veya default note’a çevirmeyecekti.
Uygulama
Public note okuması
Yerel cache
Kullanılamıyor / entry yazılmadı
Asıl store
Fallback: Tea note / version=1
Sonuç kararı
Tea note / version=1 / source=store

ROLLER · STATE · VERİ AKIŞI

Cache hangi işi tekrar etmez?

Application cache, daha önce hesaplanan veya başka bir owner’dan okunan sonucu yeniden kullanır. Atlas public Tea note’u ilk kez isterken cache miss olur: application, authoritative note store’dan version=1 ve title alanını okur, bu representation’ın kopyasını cache’e koyar ve sonucu kullanır. Sonraki hit aynı key için saklanan değeri döndürür; store’a ikinci read yapılmaz. Örnekte bu fark read counter ile görünür. Daha az read yapılması latency’nin ölçüldüğü veya her workload’un hızlandığı anlamına gelmez. Cache’e raw object, query result veya computed view konabilir; bunların kapsamı aynı değildir.

Bu katman browser HTTP cache’inden ayrıdır. Application’ın process-local dictionary’si her instance için ayrı bir kopya oluşturabilir. Redis gibi network üzerinden erişilen bir store ise shared cache owner olabilir. Shared olması bütün application-side kopyaların aynı anda güncellendiği anlamına gelmez; memory kullanımı da kendiliğinden persistence garantisi değildir. Redis server-assisted client-side caching, client belleğindeki kopyalar için invalidation notification kullanabilir. Bu dersin yerel örneği tek process içindedir; o network protocol’ünü çalıştırmaz.

Hit, seçilen key için saklanmış bir sonuç bulunduğunu söyler. Sonucun authoritative owner’daki en yeni revision olduğunu söylemez. Miss, database’de not bulunmadığını söylemez; authoritative read gerekir. Error ise cache’e erişimin başarısız olmasıdır. Bu üç sonucu aynı “veri yok” durumuna çevirmek yanlış karar doğurur. Atlas’ın public-read örneği cache error sırasında authoritative store’a başvurur. Store da unavailable ise error devam eder; uygulama boş bir not üretmez. Bu fallback politikası sensitive veya state-changing operation’lara otomatik taşınmaz.

Invalidation hangi revision’ı korur?

Cache-aside write akışında önce authoritative update commit edilir, sonra ilgili cache entry invalidate edilir. Invalidate önce yapılırsa aradaki reader eski committed değeri yeniden cache’e doldurabilir. Doğru sıra da her topology için tam consistency garantisi değildir: başka writer, geciken read veya başka instance’ın local cache’i eski representation’ı geri getirebilir. TTL, eski değerin kullanılabileceği süreyi sınırlayabilir; expiry’den önce her read’in newest state’i alacağını garanti etmez.

Atlas’ın geç fill dalında reader version=1 için candidate hazırlamıştır. Owner daha sonra version=2’ye commit olur ve cache entry silinir. Eski candidate ancak bundan sonra değerlendirilir. Örneğin serialized guard’ı candidateVersion=1 ile knownCurrentVersion=2’yi karşılaştırır ve fill’i reddeder. Cache boş kalır; sonraki fresh read version=2’yi getirir. Bu guard’ın dayanağı aynı sınır içinde güncel revision’ın bilinmesidir. Dağıtık notification, bağımsız writer veya farklı cache owner için bu varsayımı ayrıca tasarlamak gerekir.

Hareket olmadan bütün senaryoları oku

Eski fill

Eski read henüz bitmedi
Reader, Tea note için version=1 sonucunu hazırlamış. Henüz cache’e yazılmamış bu kopya, daha sonra owner değişse bile kendi başına güncellenmez.
Bekleyen reader
candidateVersion=1
Authoritative note sahibi
Tea note / version=1
Cache kabul sınırı
Fill bekliyor
Owner yeni revision’ı kaydetti
Authoritative kayıt artık Coffee note, version=2. Bekleyen reader hâlâ eski kopyayı taşıyor; bir owner’ın commit’i başka bir state’i otomatik değiştirmiyor.
Bekleyen reader
candidateVersion=1
Authoritative note sahibi
Coffee note / version=2
Cache kabul sınırı
Fill bekliyor
Cache boşaldı, eski aday kalıyor
Invalidation cached entry’yi kaldırdı. Bu örnekte kabul sınırı güncel owner revision=2 bilgisini tutuyor. Cache’in boş olması, bekleyen bütün read’lerin taze olduğu anlamına gelmez.
Bekleyen reader
candidateVersion=1
Authoritative note sahibi
Coffee note / version=2
Cache kabul sınırı
knownCurrentVersion=2 / cache empty
İki revision’ı aynı kararda karşılaştır
Eski adayın version=1 değeri, kabul sınırındaki currentVersion=2 ile eşleşmiyor. Karar, geldiği anda adayın taşıdığı revision’a göre veriliyor.
Bekleyen reader
candidateVersion=1
Authoritative note sahibi
Coffee note / version=2
Cache kabul sınırı
1 != 2 / fill decision pending
Eski kopya kabul edilmedi
accepted=false ile eski fill cache’i değiştirmiyor; cache boş kalıyor. Bu guard yalnız güncel revision’ın aynı serialized owner sınırında bilindiği örnek için geçerli.
Bekleyen reader
candidateVersion=1 / rejected
Authoritative note sahibi
Coffee note / version=2
Cache kabul sınırı
accepted=false / cache empty
Yeni read güncel owner’a dönüyor
Sonraki read’in sonucu version=2. Eski fill’in reddedilmesi ile yeni sonucun alınması ayrı gözlemler. Başka process’lerdeki kopyaların eşzamanlı güncellendiği buradan çıkarılamaz.
Bekleyen reader
nextResultVersion=2
Authoritative note sahibi
Coffee note / version=2
Cache kabul sınırı
old fill accepted=false

Owner da yok

Public read bir sonuç bekliyor
Application public note’u okumak istiyor. Cache kopyası ile authoritative kayıt farklı owner’larda; sonucu hangi owner’ın sağlayacağı henüz bilinmiyor.
Bekleyen reader
Public note sonucu bekleniyor
Authoritative note sahibi
Henüz okunmadı
Cache kabul sınırı
Cache sonucu bekleniyor
Cache erişimi hata verdi
Cache outcome=error, miss ile aynı sonuç değil. Bu public read için seçilmiş policy, kaydı authoritative owner’dan okumayı deneyecek.
Bekleyen reader
Fallback kararı bekleniyor
Authoritative note sahibi
Henüz okunmadı
Cache kabul sınırı
cacheOutcome=error
Fallback sahibi açık
Application’ın fallback hedefi authoritative store. Başarısız cache’ten uydurma bir not üretmek yerine kaydın sahibine gidiliyor.
Bekleyen reader
fallbackOwner=authoritative store
Authoritative note sahibi
Read sonucu bekleniyor
Cache kabul sınırı
cacheOutcome=error
Authoritative read de başarısız
İkinci owner da unavailable olduğunda elde doğrulanmış note sonucu yok. Cache hatasını veri yokluğu olarak yorumlamak bu eksikliği çözmez.
Bekleyen reader
Başarı sonucu yok
Authoritative note sahibi
Store unavailable
Cache kabul sınırı
cacheOutcome=error
Default not oluşturulmuyor
bothUnavailable.result=error ve createdDefaultNote=false. Application, tamamlanamayan read’i yeni bir boş record varmış gibi göstermiyor.
Bekleyen reader
result=error / createdDefaultNote=false
Authoritative note sahibi
Store unavailable
Cache kabul sınırı
cacheOutcome=error
Policy’nin kapsamını koru
Bu karar public, read-only not örneğine ait. Aynı fallback’ın private veri veya state değiştiren bütün işlemler için uygun olduğunu söylemek ayrıca policy kanıtı gerektirir.
Bekleyen reader
result=error / no default
Authoritative note sahibi
Authoritative sonuç alınamadı
Cache kabul sınırı
Public okuma politikası

VARSAYIM · SINIR · KONTROL

Hit ile freshness farklı iddialardır

Cache incelemesinde yalnız hit ratio’ya bakma. Artifact cache revision’ını ve authoritative revision’ı ayrı tutar; eski bir kopya hâlâ hit olabilir. Öğrencinin sorusu “entry var mı?”dan sonra “hangi representation, hangi revision ve ne kadar staleness kabul ediliyor?” olmalıdır. Eski computed view ile alınan karar yanlış olabilir. TTL’yi current permission veya newest state kontrolünün yerine koymak bu sınırı kaybettirir.

Bir instance’ın cache entry’sini silmek diğer instance’ın kopyasını güncellemez. Shared cache’in temizlenmesi de bütün client-side kopyaların yenilendiğini kanıtlamaz. Buradaki yanlış varsayım, bir owner’ın tamamlanmasını bütün owner’ların synchronized olmasıyla eşitlemektir. Atlas yalnız public note revision’larını izler; etkiyi bu representation’ın eski kalması üzerinden değerlendirir.

Error’ı database absence’a çevirme

Cache unavailable olduğunda get işlemi error verir; miss üretmiş sayılmaz. Public-read fallback store’dan sonuç alabilirse application o owner’ın representation’ını kullanır. Cache population’ın başarısız kalması bu store sonucunu yok etmez. Store da unavailable olduğunda boş not üretmek ise bilinmeyen bir durumu uydurma bir record’a dönüştürür. Fallback’in kaynak tüketimi ve retry davranışı kendi policy’sine göre ayrıca değerlendirilmelidir.

Geç fill dalında eski candidate ile güncel owner revision’ı uyuşmaz ve guard state’i değiştirmez. İnceleme, candidate’ın hangi revision’a ait olduğunu ve karar sırasında current revision’ın nereden bilindiğini sorar. Artifact’te karar alanı eksikse selector sonucunun sıfır olması yeterli değildir: bu sayı bazen eşleşen olay olmadığı, bazen gerekli observation bulunmadığı için sıfırdır. Eksik gözlemden “cache güncel” sonucu çıkarma.

Hareket olmadan bütün senaryoları oku

Fallback sonucu

Alanları owner’a göre ayır
Buradaki kanıtın üreticisi yerel cache adapter’ı ve note store okumasıdır; error, returnedVersion ve readCount bu örneğin alanlarıdır, hazır Redis log alanları değildir. İnceleme error bölümünü kullanıyor. Cache outcome, fallback owner, returned version ve population sonucu aynı şeyin farklı adları değil; her biri ayrı bir soruya cevap veriyor.
Cache gözlemi
error / seçilmiş alanlar
Sonuç kaynağı
Sonuç kaynağı henüz okunmadı
Kanıt yorumu
Yorum bekliyor
Error ile miss’i ayır
cacheOutcome=error, cache erişiminin tamamlanamadığını gösteriyor. Kayıt cache’te yokmuş gibi bir miss saymak, hangi bileşenin başarısız olduğunu gizler.
Cache gözlemi
cacheOutcome=error
Sonuç kaynağı
Sonuç kaynağı henüz okunmadı
Kanıt yorumu
Cache hatası; kayıt yokluğu değil
Fallback owner’ı oku
fallbackOwner=authoritative store. Sonuç başarılıysa bunun kaynağı cache değil, kaydın authoritative sahibi olacak.
Cache gözlemi
cacheOutcome=error
Sonuç kaynağı
fallbackOwner=authoritative store
Kanıt yorumu
Result version bekleniyor
Dönen revision ayrı kanıt
returnedVersion=1 bu read’in sonucunu tanımlar. Tek başına bu sayı cache’in yeniden dolduğunu veya farklı process’lerdeki kopyaların yenilendiğini göstermez.
Cache gözlemi
cacheOutcome=error
Sonuç kaynağı
returnedVersion=1 / source=store
Kanıt yorumu
Owner sonucu var; cache sonucu ayrı
Population başarılı değil
cachePopulationSucceeded=false kalıyor. Application doğru owner’dan bir not döndürebilirken cache hâlâ kullanılamıyor; iki başarı kriterini birleştirme.
Cache gözlemi
cachePopulationSucceeded=false
Sonuç kaynağı
returnedVersion=1 / source=store
Kanıt yorumu
Read success != cache recovery
Desteklenen iddiayı seç
Bu kayıt, public read sonucunun authoritative store’dan geldiğini destekliyor. Cache recovery, latency kazancı veya bütün outage koşullarında resilience için burada kanıt yok.
Cache gözlemi
cacheOutcome=error / population=false
Sonuç kaynağı
returnedVersion=1 / source=store
Kanıt yorumu
Public read fallback doğrulandı

Eksik gözlem

Stale-fill kaydını seç
Buradaki kanıtın üreticisi yerel cache adapter’ı ve note store okumasıdır; error, returnedVersion ve readCount bu örneğin alanlarıdır, hazır Redis log alanları değildir. Öğretim kaydında candidateVersion ile currentVersion karşılaştırılır. Kabul kararı için fillAccepted alanının da bulunması gerekir.
Cache gözlemi
candidateVersion=1 / currentVersion=2
Sonuç kaynağı
fillAccepted henüz okunmadı
Kanıt yorumu
Kabul sonucu bilinmiyor
Bu örnekte kabul alanı eksik
Eksik gözlem dalında fillAccepted verilmemiş. Bu alanı false olarak doldurmak, mevcut kanıtı öğrencinin varsayımıyla tamamlamak olur.
Cache gözlemi
candidateVersion=1 / currentVersion=2
Sonuç kaynağı
fillAccepted=unknown
Kanıt yorumu
Kabul sonucu bilinmiyor
Selector yalnız gördüğünü sayar
Stale revision’ın kabul edildiğini arayan selector eşleşme bulmayabilir. Ancak kabul alanı eksik olduğunda sıfır eşleşme, reject kararı için kanıt değildir.
Cache gözlemi
candidateVersion=1 / currentVersion=2
Sonuç kaynağı
fillAccepted=unknown / no matching record
Kanıt yorumu
Zero matches != proven reject
Gerekli ek gözlemi belirle
Aynı fill denemesi için kabul sonucunu ve hangi güncel owner revision’ına göre karar verildiğini iste. Başka bir fill’in sonucu bu denemeyi tamamlamaz.
Cache gözlemi
candidateVersion=1 / currentVersion=2
Sonuç kaynağı
Aynı fill için karar eksik
Kanıt yorumu
Aynı attempt için kabul kanıtı gerekir
Bilinen tam örnekle farkı gör
Tam lateFill kaydında accepted=false ve cacheEmptyAfterReject=true birlikte bulunur. Bu tam kaydın sonucu, eksik dalda aynı olay gözlenmiş gibi kopyalanamaz.
Cache gözlemi
candidateVersion=1 / currentVersion=2
Sonuç kaynağı
complete example: accepted=false
Kanıt yorumu
Eksik dalın sonucu bilinmiyor
Belirsizliği sonuçta koru
Eksik dal için sonuç “yetersiz kanıt”. Bu, cache’in hatalı çalıştığını da doğru çalıştığını da kanıtlamıyor. İnceleme alanın eksikliğini açık tutuyor.
Cache gözlemi
candidateVersion=1 / currentVersion=2
Sonuç kaynağı
fillAccepted=unknown
Kanıt yorumu
Yetersiz kanıt

UYGULAMA · GÜVENLİK KONTROLÜ · DOĞRULAMA

Cache contract’ı gözlenebilir olsun

Buradaki kanıtın üreticisi yerel cache adapter’ı ve note store okumasıdır; error, returnedVersion ve readCount bu örneğin alanlarıdır, hazır Redis log alanları değildir. Cache key’in hangi representation ve revision’ı tanımladığını açıkça yaz. Application’a verilen object’in cache içinde saklanan object ile aynı mutable referans olması istenmiyorsa kopyalama sınırını da tanımla. Atlas’ın ilk miss’i authoritative readCount’u artırır; sonraki hit artırmaz. Bu sayaç seçilen adapter’ın read sayısıdır, Redis statistics veya latency ölçümü değildir. Cache’in authoritative record owner olmadığı ayrımı korunur.

Cache error ile store error için ayrı outcome kaydet. Public-read fallback’te result’un hangi owner’dan geldiği görünür olmalıdır; store failure sırasında default object üretilmemelidir. Result contract’ı gerçek uygulamada purpose, permission ve kabul edilen staleness koşullarını da taşır. Browser için HTTP Cache-Control tanımlamak bu server-side dictionary’yi kendiliğinden invalidate etmez; iki cache katmanının policy’si ayrıdır.

Commit, invalidate ve refill’i ayrı izle

Normal update’de store version=2’ye commit olur, invalidate entry’yi kaldırır ve sonraki read yeni revision’ı cache’e doldurur. Her adım kendi owner state’ini değiştirir; başarılı invalidation cross-owner atomic transaction değildir. Geç candidateVersion=1 reddedildiğinde cache boş kalır. Fresh read’den sonra version=2 görülür. Son değere bakmakla yetinmeyip bu geçişlerin sırasını ve decision alanlarını da incele.

Revision guard ancak kararın alındığı sınırda current revision güvenilir biçimde biliniyorsa anlamlıdır. Farklı process’ler, geciken notification’lar ve bağımsız writer’lar bu koşulu değiştirebilir. Atlas’ın yerel guard’ı bunları çözmüş sayılmaz. Eksik decision kaydı UNKNOWN olarak kalır; aynı sonuca ulaşmış başka request’in observation’ı bu request’in boşluğunu doldurmaz.

ŞİMDİ VAKAYA UYGULA

Cache boşaltıldıktan sonra gelen eski read sonucu hangi revision’ı taşıyor?

Duru, Atlas’taki public Tea note kaydını okuyor. Kayıt sahibi başlığı Coffee note olarak güncellerken daha önce başlamış bir read hâlâ version=1 taşıyor. Cache’in boşaltılması bu bekleyen kopyayı kendiliğinden yenilemez.

Vakadaki representation hangi cache owner’dan geliyor? Key kapsamı, freshness ve kullanıcının context’ini birlikte değerlendir; hit olması doğru viewer’a ait olduğunu kanıtlamaz.

Bağlı vaka dosyasını aç ↗

ÖRNEĞİ BİRLİKTE OKUYALIM

Public note cache/revision ledger

Bir alan seç; hangi sonucu desteklediğini ve nerede yetersiz kaldığını incele.

Ham kaydı ve alan açıklamalarını oku

{
  "selectedPolicy": {
    "cache": "own process-local copy dictionary",
    "authoritativeStore": "own public-note memory adapter",
    "redisExecuted": false,
    "httpCache": false,
    "errorFallback": "authoritative read for public read only",
    "revisionGuard": "serialized known owner revision; not distributed guarantee"
  },
  "normal": {
    "firstResult": {
      "id": "tea",
      "title": "Tea note",
      "version": 1
    },
    "firstCacheOutcome": "miss",
    "storeReadsAfterFirst": 1,
    "secondCacheOutcome": "hit",
    "storeReadsAfterSecond": 1,
    "applicationMutationChangesCache": false
  },
  "update": {
    "committedValue": {
      "id": "tea",
      "title": "Coffee note",
      "version": 2
    },
    "order": [
      "store commit",
      "cache invalidate",
      "next read/refill"
    ],
    "cacheEmptyAfterInvalidate": true,
    "refillVersion": 2
  },
  "lateFill": {
    "candidateVersion": 1,
    "knownCurrentVersion": 2,
    "accepted": false,
    "cacheEmptyAfterReject": true,
    "nextResultVersion": 2
  },
  "error": {
    "cacheOutcome": "error",
    "fallbackOwner": "authoritative store",
    "returnedVersion": 1,
    "cachePopulationSucceeded": false
  },
  "bothUnavailable": {
    "result": "error",
    "createdDefaultNote": false
  },
  "selector": {
    "language": "XPath",
    "xml": "<audit><cache candidateVersion=\"1\" currentVersion=\"2\" fillAccepted=\"false\"/></audit>",
    "xpath": "count(/audit/cache[@candidateVersion != @currentVersion and @fillAccepted='true'])",
    "expected": 0,
    "positiveFixtureXml": "<audit><cache candidateVersion=\"1\" currentVersion=\"2\" fillAccepted=\"true\"/></audit>",
    "positiveExpected": 1,
    "scope": "Only authored protocol-decision observations, not product log field names or a live HTTP capture.",
    "missingFieldBehavior": "Missing observation is insufficient evidence; zero matches is not proof of correct runtime behavior."
  }
}

normal: Miss/hit’in authoritative read count’u.
update/lateFill: Commit/invalidate/refill ve serialized version guard.
error/bothUnavailable: Error fallback owner ve default state yokluğu.
selector: Synthetic stale-fill acceptance kararı.

Own local memory adapters; gerçek Redis/ElastiCache veya latency/cluster ölçümü değildir. Guard’ın current-owner varsayımı açıktır.

İki yanlış kanı

Cache hit en güncel authoritative state’i kanıtlar.

Hit cached result bulur; freshness ayrı lifetime/invalidation/consistency contract’ına bağlıdır.

Invalidate ettim; geç kalan eski read cache’e tekrar yazamaz.

Selected concurrency sequence eski fill’i getirebilir; local condition’ın revision owner scope’u açık olmalıdır.

SIRA SENDE

Bu hikâyeyi sen çöz.

Sonucu tahmin et, kanıtın sınırını bul ve nedenini kendi cümlenle anlat.

Bilinen güncel version=2, fakat geciken cache fill version=1 getiriyor. Bu sonuç cache’e kabul edilir mi?

Hayır. cacheEmptyAfterReject=true; sonraki read version=2 döndürür.
Evet. Son tamamlanan fill her zaman cache’in üzerine yazmalıdır.

Gerekçeli cevabı oku

Hayır. cacheEmptyAfterReject=true; sonraki read version=2 döndürür. — Bu yerel modelde revision kontrolü, eski adayın daha yeni kaydı gölgelemesini engeller. Reddedilen fill sonrasında cache boş kalır.

Cache hatasında public-read fallback ile hem cache hem store erişilemezken verilen sonuç neden farklıdır?

Dersten seçilen artifact alanları; öğretim örneği

error: {"cacheOutcome":"error","fallbackOwner":"authoritative store","returnedVersion":1,"cachePopulationSucceeded":false}
bothUnavailable: {"result":"error","createdDefaultNote":false}

Her cache hatası miss sayılır ve varsayılan resource oluşturulur.
Cache hatasında store’dan okunabilir; ikisi de erişilemezse hata döner.

Gerekçeli cevabı oku

Cache hatasında store’dan okunabilir; ikisi de erişilemezse hata döner. — Bu public-read policy’si, cache hatasında authoritative store’a başvurabilir. Store’un durumu da bilinmiyorsa veri uydurmaz veya varsayılan note oluşturmaz.

Store commit → cache invalidate → refill sırası neden bütün node’larda invalidation garantisi değildir?

Gerekçeli cevabı oku

Bu örnekte yerel dictionary, authoritative store write işleminden sonra invalidate edilir. Sonraki read version=2 ile cache’i yeniden doldurur. Revision kontrolü, aynı owner’ın sırayla işlediği bilinen state’i kullanır; node’lar arasındaki invalidation delivery veya replication ölçülmez. Bu application cache, browser HTTP cache’i değildir; Redis de çalıştırılmamıştır (RedisExecuted=false).

□ Yerel revision kontrolünden distributed garanti çıkarmadım.

□ Application cache ile HTTP cache’i ayrı açıkladım.

Uygulama konsolunu aç · request / response / browser

Request, URL, cookie ve DOM örneklerini ayrıca aç

Kaynaklar ve kapsam

Microsoft Learn — Cache-Aside patternContext and problem · Solution · Problems and considerations
Amazon ElastiCache — Caching strategies for MemcachedLazy loading · Advantages and disadvantages of lazy loading · Adding TTL
Redis — Client-side caching referenceClient-side caching reference · There are two hard problems in computer science... · The Redis implementation of client-side caching · Avoiding race conditions
Redis — GETGET command description · Return information
Redis — Key evictionUsing the maxmemory configuration directive · Eviction policies

KENDİ NOTUN / BU TARAYICIDA

Application cache ve invalidation

1. Core · Mekanizma

Miss, sonra hit

Late old fill

Cache error

Cache hangi işi tekrar etmez?

Invalidation hangi revision’ı korur?

2. Red · Güven ve etki

Eski fill

Owner da yok

Hit ile freshness farklı iddialardır

Error’ı database absence’a çevirme

3. Blue · Güvenli geliştirme ve savunma

Fallback sonucu

Eksik gözlem

Cache contract’ı gözlenebilir olsun

Commit, invalidate ve refill’i ayrı izle

Cache boşaltıldıktan sonra gelen eski read sonucu hangi revision’ı taşıyor?

İki yanlış kanı

Bilinen güncel version=2, fakat geciken cache fill version=1 getiriyor. Bu sonuç cache’e kabul edilir mi?

Cache hatasında public-read fallback ile hem cache hem store erişilemezken verilen sonuç neden farklıdır?

Store commit → cache invalidate → refill sırası neden bütün node’larda invalidation garantisi değildir?

Kaynaklar ve kapsam