Caching bir performans özelliği değildir

Bir sistem yavaşladığında bu söz erkenden duyulur: "O zaman bunu cache'leriz." Küçük, yerel bir önlem gibi gelir kulağa — birkaç satır, bir anahtar, bir süre sonu. Gerçekte ise o anda verilebilecek en sonuç doğurucu mimari kararlardan birini verirsiniz: Doğrunun ikinci bir kopyasını oluşturur ve onu birincisiyle uyumlu tutmayı taahhüt edersiniz. Sonrasında zorlaşan her şeyin — yanlış veriler, gizemli bug'lar, yük altındaki kesintiler — kökeni buradadır.

Bu metin caching'i gerçekte olduğu şey olarak ele alıyor: hızla değil, tutarlılıkla ilgili bir karar. Bilinçli olarak framework'ten, veritabanından ve bulut sağlayıcısından bağımsız tutuldu. İlkeler bir tarayıcı önbelleği için de, bir CDN, süreç içi bir in-memory önbellek ya da birçok düğüme yayılmış dağıtık bir önbellek için de geçerlidir.

1. Caching neden yanlış anlaşılır

Yanlış anlama kategoriyle başlar. Caching; indeksler, sıkıştırma ve daha hızlı sunucuların yanında "performans" başlığı altına yazılır. Ancak bu önlemler yalnızca aynı doğrunun ne kadar hızlı sunulduğunu değiştirir. Önbellek ise başka bir şeyi değiştirir: Muhtemelen eskimiş bir doğruyu — hızlıca — sunar. Gecikmedeki kazanç, güncellikteki bir kayıpla ödenir. Bu dar anlamda bir optimizasyon değil, bir takastır.

Caching'in bu kadar cazip görünmesinin nedeni gerçektir: Çoğu sistem yazdığından çok daha sık okur ve aynı veriler tekrar tekrar talep edilir. Bir değeri bir kez hesaplayıp defalarca sunmak gerçek bir iş tasarrufu sağlar. Sorun caching'in işe yaramaması değildir — neredeyse fazla iyi işe yarar. Yavaşlığı o kadar güvenilir şekilde gizler ki, aslında çözülmesi gereken yapısal sorunları da örter.

Bu metnin tamamını taşıyan bir tutum buradan çıkar: Önbellek, tahmin edilen bir soruna verilen refleks değil, ölçülmüş bir sorunun cevabıdır. Cache'lemeden önce neyin yavaş olduğunu ve nedenini bilmeniz gerekir. Neden çoğu zaman eksik bir veritabanı indeksinde, bir N+1 sorgusunda ya da senkron gerçekleşen ama asenkron olması gereken bir çağrıdadır. Bu durumlarda önbellek belirtiyi giderir ve hastalığı konserve eder.

Ödünleşim. Önbellek, tutarlılığı ve sadeliği gecikme ve kaynağın yükünün hafiflemesiyle takas eder. İkisi de gerçektir; hiçbiri bedava değildir.

Maliyet. Önbelleğe alınan her büyüklük, bir doğrunun bulunduğu yerlerin sayısını ikiye katlar. Bu ikilemenin bakımını birinin yapması gerekir — kodda, zihinde ve işletimde. Asıl maliyet kalemi bellek değil, invalidasyona yönelik kalıcı yükümlülüktür.

Ne zaman farklı karar veririz. Bir sorun kaynağında temiz şekilde çözülebiliyorsa — eksik bir indeks, ayrıştırılmış bir hesaplama, daha iyi bir sorgu — onu orada çözer ve cache'lemeyiz. Önbelleğe ancak kaynak olabileceği kadar hızlı olduğunda ve kalan yük salt tekrardan kaynaklandığında başvururuz.

Şema: Önbellek, istek ile köken arasında durur. Bir kopya tuttuğu andan itibaren ikisi birbirinden ayrışabilir — her caching sorusunun özü budur.

2. Asla önbelleğe alınmaması gerekenler

Nasıl cache'leneceği sorusundan önce neyin cache'lenebileceği sorusu gelir. Bazı veriler eskimeyi kaldırır, bazıları kaldırmaz. Sınır, eskimiş bir cevabın yalnızca hoş olmayan değil, yanlış ya da tehlikeli olduğu yerden geçer.

Yetkilendirme ve izin kararları önbelleğe alınmamalıdır. Birinin bir şeyi yapmaya yetkili olup olmadığı, daha önceki bir çağrının anında değil, eylemin anında geçerli olmalıdır. Yetki geri alındıktan sonra "izinli" diyen bir önbellek bir performans kazancı değil, bir güvenlik açığıdır. Aynı şekilde kişisel veriler ya da tenant'a (müşteri hesabına) bağlı veriler de kimliğe göre katı bir ayrım olmadan paylaşılan bir önbelleğe konmamalıdır — bir kullanıcının başka birinin verilerini görmesinin en yaygın nedeni, kimliği içermeyen bir önbellek anahtarıdır.

Ayrıca okundukları anda doğru olması gereken değerler de önbelleğe alınmamalıdır: bir para çekiminden önceki güncel hesap bakiyesi, bir siparişin son adımındaki mevcut stok, hukuken bağlayıcı olarak taahhüt edilen bir fiyat. Bu tür büyüklükler için "neredeyse güncel", "yanlış" ile eş anlamlıdır.

Ödünleşim. Cazibe, bu değerleri de cache'lemektir, çünkü çoğu zaman yoğun şekilde talep edilirler. Ancak takas, gecikmeye karşı doğruluk olurdu — ve paranın, hukukun ya da erişimin söz konusu olduğu yerde doğruluk pazarlık konusu değildir.

Maliyet. Bu verileri kaynağında hızlı tutmak gerçek emek ister: indeksler, yalın sorgular, gerekirse özel bir okuma modeli. Bu maliyetleri, doğruluğu tehlikeye atan bir önbelleğe kaydırmak yerine bilinçli olarak üstlenirsiniz.

Ne zaman farklı karar veririz. Bu tür değerlerin kendisini cache'lemeden türetilmelerini cache'leyebilirsiniz — örneğin sonucu en sonda yine de canlı duruma karşı kontrol edilen pahalı bir toplama (aggregation). O zaman otorite kaynakta kalır ve önbellek yalnızca ön çalışmayı taşır.

3. Önbellek invalidasyonu

Bilgisayar biliminde yalnızca iki zor sorun olduğuna dair bilinen söz — önbellek invalidasyonu ve şeylere isim vermek — yarı yarıya ciddidir. İnvalidasyon zordur, çünkü değişiklik tamamen başka bir yerde gerçekleşmiş olsa bile bir sistemin bir kopyanın ne zaman geçersiz hâle geldiğini bilmesini gerektirir. Bu bilgiyi organize etmenin özünde üç yolu vardır.

Birincisi süre sonudur: Kopyaya belirli bir süre güvenir ve ardından onu atarsınız. İkincisi aktif geçersiz kılmadır: Doğruyu değiştiren, ilgili kopyayı hedefli olarak siler ya da üzerine yazar. Üçüncüsü olay güdümlü invalidasyondur: Değişiklikler olaylar üretir ve önbellek bunlara tepki verir. Üçü birbirini dışlamaz; sağlam sistemler bunları birleştirir.

Aktif geçersiz kılmanın en zor kısmı silmenin kendisi değil, eksiksizliktir: Doğrunun değişebileceği her yol kopyayı geçersiz kılmalıdır. Bir yazma yolu unutulursa — bir içe aktarma, bir yönetici aracı, bir arka plan işi — geride yanlış bir kopya kalır ve hata yalnızca ara sıra kendini gösterir. Süre sonunun zayıflığına rağmen bu kadar yaygın olmasının nedeni tam da budur: Bir yazma yolunu gözden kaçırdığınızda bile işe yarayan tek stratejidir.

Ödünleşim. Aktif ve olay güdümlü geçersiz kılma, güncelliği bağımlılık (coupling) ve eksiksizlik yükümlülüğü karşılığında satın alır. Süre sonu ise sadeliği garanti edilmiş ama sınırlı bir eskime karşılığında satın alır.

Maliyet. En pahalı varyant olay güdümlü olanıdır: Güvenilir bir olay dağıtımı ve dolayısıyla dağıtık mesaj işlemenin de gerektirdiği disiplinin bir kısmını ister — kaybolan bir olayda ne olacağı sorusu dahil.

Ne zaman farklı karar veririz. Temel çizgi olarak süre sonunu seçeriz, çünkü eksik bilgi durumunda bile güvenlidir. Aktif geçersiz kılmayı, yazma yollarının sınırlı olduğu ve süre sonu penceresindeki eskimenin hissedilir şekilde rahatsız ettiği yerlerde ekleriz. Olay güdümlü yaklaşıma ancak çok sayıda bağımsız yazıcı olduğunda ve bir olay altyapısı zaten mevcut olduğunda geçeriz.

4. Önbellek ömürleri

Ömür — bir kopyaya güvendiğiniz süre — şu sorunun vekil büyüklüğüdür: Bu değer ne kadar eskimeyi kaldırır? Bu teknik değil, iş alanına dair bir karardır ve global olarak değil, veri türü başına verilmelidir.

Fazla uzun bir ömür eskimiş veriler gösterir ve sisteme duyulan güveni sarsar. Fazla kısa bir ömür ise kopyayı kendini amorti etmeden önce atar ve isabet oranını, önbelleğin faydadan çok yönetim yükü getireceği ölçüde düşürür. Bu iki kutup arasında evrensel bir değer yoktur; yalnızca somut değerin hangi eskime düzeyinde rahatsız edecek kadar yanlış hâle geldiği sorusu vardır.

İki mekanizma sert süre sonunu yumuşatır. Birincisi, kopyanın süresi dolmadan önce arka planda yeniden hesaplamadır: Eski kopya hâlâ sunulurken değer yenilenir, böylece kimse hesaplamayı beklemez. İkincisi, hata durumunda süresi biraz geçmiş kopyalara tolerans göstermektir: Kaynağa ulaşılamıyorsa, bir hata göstermek yerine bilinçli olarak eskimiş bir kopya sunulur. İkisi de takası erişilebilirlik lehine kaydırır — ve garanti edilen güncelliği daha da gevşettikleri için bilinçli olarak seçilmelidir.

Ödünleşim. Ömür, güncelliği isabet oranı ve yükün hafiflemesiyle takas eder. Her uzatma, yükün hafiflemesini ve eskimeyi aynı anda artırır.

Maliyet. Arka planda yeniden hesaplama ek karmaşıklığa mal olur ve yükü süre sonundan hemen önceki zamana kaydırır; dağıtma (jitter) olmadan bu kolayca kaynağa eşzamanlı bir hücuma dönüşür (bkz. hata modları).

Ne zaman farklı karar veririz. Nadiren yanlış olduğunda zarar veren veriler için cömert ömürler seçer ve görünür eskimeyi kabul ederiz. Paraya ya da hukuka yakın veriler için çok kısa ömürler seçer ya da hiç cache'lemeyiz. Pahalı ama nadiren değişen toplamalar için uzun bir ömrü yazma sırasında aktif geçersiz kılmayla birleştiririz — yükü hafifletecek kadar uzun, ancak doğru değiştiğinde anında düzeltilen.

5. Caching katmanları

Caching nadiren tek bir yerde gerçekleşir. Kullanıcı ile veri kaynağı arasında birden fazla katman bulunur ve her biri bir kopya tutabilir. Bunları bilmek önemlidir, çünkü bir değer aynı anda birden fazla katmanda eskiyebilir ve invalidasyon üzerindeki kontrol katmandan katmana azalır.

Şema: Kopya kullanıcıya ne kadar yakınsa gecikme kazancı o kadar büyüktür — ve ondan yeniden kurtulma üzerindeki kontrol o kadar azdır.

İstemcideki katman en büyük gecikme kazancını sağlar, çünkü istek cihazdan hiç çıkmaz — ancak orada duran bir kopyayı pratikte geri çağıramazsınız. Bu yüzden istemciye yalnızca ömrü net şekilde sınırlı ve başkasının kimliğini içermeyen şeyler aittir. Uygulamadaki katman kontrol edilmesi en kolay olanıdır, ancak düğüm başına ayrıdır: Birden fazla instance'ı olan bir sistemde her biri kendi kopyasını tutar ve aynı büyüklük iki düğümde farklı yaşta olabilir.

Ödünleşim. Daha fazla katman, yükün daha fazla hafiflemesi ve kullanıcıya daha fazla yakınlık demektir; ancak aynı doğrunun farklı şekilde eskiyebileceği daha fazla yer de demektir.

Maliyet. Her ek katman invalidasyon emeğini katlar ve teşhisi zorlaştırır: Yanlış bir yanıtta, onu hangi katmanın verdiğini bilmeniz gerekir.

Ne zaman farklı karar veririz. Bilinçli olarak mümkün olduğunca az katmanda cache'ler ve katmanı amaca göre seçeriz: herkese açık, herkes için aynı yanıtları kenarda; pahalı, dahili hesaplamaları uygulamada. Aynı büyüklük için birden fazla katmanı ancak her birinin kendine ait, adı konmuş bir amacı varsa birleştiririz — asla "ne olur ne olmaz" diye değil.

6. Dağıtık önbellekler

Bir sistem birden fazla düğümden oluştuğu anda süreç içi önbellek artık yeterli olmaz, çünkü her düğüm kendi doğrusunu tutar. Dağıtık bir önbellek — tüm düğümlerin paylaştığı bir depolama — bu sorunu çözer ve yeni bir sorun yaratır: Önbelleğin kendisi çökebilen, yavaşlayabilen ve aşırı yüklenebilen bir bileşen hâline gelir. Artık yalnızca bir hızlandırıcı değil, erişilebilirliğin bağlı olduğu sistemin bir parçasıdır.

Böylece soru değişir. Yerel önbellekte soru şuydu: Kopyamı nasıl güncel tutarım? Dağıtık önbellekte buna şu eklenir: Önbellek yanıt vermezse ne olur? Önbelleği olmadan artık çalışmayan bir sistem, veritabanını yalnızca başka, çoğu zaman daha az kalıcı bir bağımlılıkla takas etmiş olur. Bu yüzden dağıtık önbellek diğer her ağ bağımlılığı gibi ele alınmalıdır: zaman aşımlarıyla, hata durumunda tanımlı bir davranışla ve zaman zaman ortada olmayacağı varsayımıyla.

İkinci bir özellik, eşzamanlılık altında önbellek ile kaynak arasındaki tutarlılıktır. İki düğüm aynı değeri aynı anda değiştirip önbelleği güncellerse, sonucu sıra belirler — ve ağdaki sıra garanti edilmez. "Oku, değiştir, önbelleğe yaz" kalıbı ek bir önlem olmadan bir yarış durumudur (race condition). Daha güvenilir temel yaklaşım, bir değişiklikte kopyanın üzerine yazmak yerine onu kaldırmaktır; böylece bir sonraki okuyucu onu kaynaktan taze olarak alır.

Ödünleşim. Dağıtık bir önbellek, düğümler arasındaki tutarsızlığı yeni, paylaşılan bir bağımlılık ve onun çökme riskiyle takas eder.

Maliyet. Artık ek, durum tutan (stateful) bir sistem işletirsiniz: Bellek planlaması, bir tahliye (eviction) stratejisi, izleme ve dolduğunda ya da ortadan kalktığında ne yapılacağına dair bir plan gerektirir.

Ne zaman farklı karar veririz. Bir sistem tek bir düğümde çalıştığı ya da düğümler küçük, tolere edilebilir sapmaları kaldırabildiği sürece yerel önbellekte kalırız — daha basittir ve ağ bağımlılığı yoktur. Dağıtık önbelleği, düğümler arasındaki sapma iş açısından rahatsız ettiğinde ya da cache'lenecek miktar tek tek her süreç için fazla büyüdüğünde devreye alırız.

7. Hata modları

Bir önbellek yalnızca normal durumdaki davranışı değiştirmez; onsuz var olmayacak kendine özgü hata tabloları da yaratır. Bunlar tipik olarak yük altında ortaya çıkar — yani tam da önbelleğin aslında yardımcı olması gereken anda.

En bilineni, süre sonundan sonraki eşzamanlı hücumdur; çoğu zaman "stampede" olarak adlandırılır: Sıcak bir değerin süresi dolar ve bekleyen tüm istekler aynı anda kaynağa erişir, çünkü henüz hiçbiri yeni kopyayı yazmamıştır. Kaynağı koruması gereken önbellek, yükü dindirmek yerine artırır. Çareler; yalnızca bir isteğin yeniden hesaplama yapması, diğerlerinin ise beklemesi ya da eski kopyayı alması için bir kilit ve çok sayıda değerin aynı anda süresinin dolmaması için süre sonu zamanlarının dağıtılmasıdır.

İkincisi, hiç var olmayan bir şeye yönelik istektir: Bir değer kaynakta yoksa önbellek onu asla bulamaz ve her istek kaynağa kadar iner. Bu durum dışarıdan tetiklenirse aşırı yüklenmeye yol açabilir. Çare, yokluğu da cache'lemektir — kısa ömürlü bir "yok" kaydı —; ancak böyle bir kaydın değerin sonradan oluşturulmasını örtmemesine dikkat edilmelidir.

Üçüncüsü, önbelleğin tamamen çökmesidir: Paylaşılan bir önbellek katmanı çökerse, tüm yük hiç bu yüke göre tasarlanmamış olan kaynağa birdenbire biner. Önbelleği olmadan hayatta kalamayan bir sistem böylece bir tekil hata noktasına (single point of failure) sahip olur. Çare önbellekte değil, kaynağın tasarımındadır: Kaynak ani bir yük tepe noktasını en azından kısıtlanmış (throttled) şekilde atlatabilmelidir.

Ödünleşim. Bu hatalara karşı koruma mekanizmaları — kilitler, dağıtma, negatif caching — karmaşıklığı artırır ve yeni uç durumlar getirebilir.

Maliyet. Bu hatalar çoğu zaman ancak gerçek yük altında ortaya çıkar ve yeniden üretilmeleri zordur. Onları görmezden gelmenin bedeli, tam da talebin en yüksek olduğu anda bir kesintidir.

Ne zaman farklı karar veririz. Nadiren talep edilen ya da kritik olmayan değerler için zahmetli koruma mekanizmalarından vazgeçer ve nadir bir hücumda kısa bir ek yükü kabul ederiz. Sıcak, pahalı değerler için kilit ve dağıtmayı baştan kurarız, çünkü orada stampede'in gerçekleşip gerçekleşmeyeceği değil, ne zaman gerçekleşeceği sorusu vardır.

8. Gözlemlenebilirlik

Ölçemediğiniz bir önbellek bir tahmindir. Metrikler olmadan ne yardımcı olup olmadığını ne de şu anda yanlış veri sunup sunmadığını bilirsiniz. Bu yüzden gözlemlenebilirlik bir ek değil, bir önbelleğin sorumluluğunu üstlenebilmenin ön koşuludur.

İlk büyüklük isabet oranıdır — önbellekten karşılanan isteklerin payı. Önbelleğin amacını yerine getirip getirmediğini söyler. Sürekli düşük bir isabet oranı, faydasını toplamadan kopyanın maliyetini taşıdığınız anlamına gelir ve ömrü, anahtar tasarımını ya da cache'leme kararını yeniden düşünmek için bir sinyaldir. İkincisi tahliye oranıdır — kayıtların yer yetersizliği nedeniyle ne sıklıkla çıkarıldığı —, çünkü yüksek tahliye isabet oranını sessizce aşındırır. Üçüncüsü önbelleğin kendi gecikmesidir: Yavaş yanıt veren dağıtık bir önbellek, yerine geçmesi gereken kaynaktan daha pahalı olabilir.

Daha zor ama daha önemli olan, doğruluğun gözlemlenmesidir. İsabet oranları, isabetlerin doğru olup olmadığı hakkında hiçbir şey söylemez. Bu yüzden ciddi bir önbelleğe, bir yanıtın yaşını ve kökenini — hangi katmandan geldiğini ve kopyanın ne kadar eski olduğunu — görünür kılma yeteneği de aittir; böylece yanlış bir yanıtta tahmin yürütmek yerine sorumlu katmanı bulursunuz.

Ödünleşim. Ölçüm ve işaretleme biraz işlem süresi ve belleğe mal olur ve sıcak yola enstrümantasyon ekler.

Maliyet. Bu enstrümantasyon olmadan önbellek hataları, teşhis edilmesi en zor sorunlar arasındadır, çünkü hata mesajı olmadan ara sıra yanlış veriler olarak kendini gösterirler.

Ne zaman farklı karar veririz. Etkisi net şekilde sınırlı, küçük ve yerel bir önbellek için basit isabet sayaçları yeterlidir. Paylaşılan ya da dağıtık her önbellek için isabet oranını, tahliyeyi, gecikmeyi ve yanıtın kökenini zorunlu görürüz — sonradan eklenen bir add-on olarak değil, bir mimari ilke olarak observability anlayışıyla.

9. Sık yapılan hatalar

Caching'in başarısız olduğu tekrarlayan kalıplar — neredeyse hepsi, önbelleği bedava sanma hatasının varyasyonlarıdır:

• Önce ölçmeden cache'lemek — belirtiyi hafifletip asıl nedeni kaynakta konserve etmek.
• Yetkileri, tenant'a bağlı ya da paraya yakın verileri cache'lemek ve böylece buna izin olmayan yerde doğruluğu gecikmeyle takas etmek.
• Kimliği önbellek anahtarından çıkarmak; böylece bir kullanıcının başka birinin kopyasını alması.
• Yalnızca kopyanın yazılmasını düşünüp geçersiz kılınmasını düşünmemek — gözden kaçan her yazma yolu yanlış bir kopya bırakır.
• Veri türü başına tolere edilebilir eskimeye göre ayarlamak yerine her şey için tek bir global ömür seçmek.
• Süre sonu zamanlarını dağıtmamak; böylece çok sayıda değerin aynı anda süresinin dolması ve kaynağa aynı anda yüklenmesi.
• Dağıtık önbelleği güvenli bir kaynak gibi ele almak — zaman aşımı olmadan, çöktüğünde tanımlı bir davranış olmadan.
• Değişikliklerde kopyayı kaldırmak yerine üzerine yazmak ve böylece eşzamanlılık altında bir yarış durumu yaratmak.
• Bir değerin yokluğunu cache'lememek ve böylece tekrarlanan boş isteklerin kaynağa kadar inmesine izin vermek.
• Önbelleği ölçmemek ve bu yüzden kullanıcılar yanlış veri bildirene kadar ne faydasını ne de zararını fark etmek.

10. Karar kontrol listesi

Bir önbelleği devreye almadan önce sırasıyla netleştirilmesi gerekenler:

• Ölçüldü mü? Neyin yavaş olduğu ve nedeni kanıtlandı mı — ve nedenin kaynakta (indeks, sorgu, senkron çağrı) daha iyi giderilebileceği olasılığı dışlandı mı?
• Bu değer eskiyebilir mi? Biraz eskimiş bir yanıt burada zararsız mı — ve değer yetkilendirme, tenant ayrımı ya da paraya yakınlık alanında değil mi?
• Anahtar eksiksiz mi? Önbellek anahtarı, yanıtı ayırt eden her şeyi, özellikle kullanıcının ya da tenant'ın kimliğini içeriyor mu?
• İnvalidasyona karar verildi mi? Süre sonuyla mı, aktif olarak mı yoksa olay güdümlü mü geçersiz kılınacağı net mi — ve aktif geçersiz kılmada tüm yazma yolları kapsandı mı?
• Veri türü başına ömür? Süre global olarak belirlenmemiş, tolere edilebilir eskimeden türetilmiş mi?
• Katman bilinçli seçildi mi? Kopya amaca uygun katmanda mı — ve "ne olur ne olmaz" diye birden fazla katmanda değil mi?
• Hata modları düşünüldü mü? Stampede (kilit, dağıtma), boş istekler (negatif caching) ve önbellek çökmesi (kaynak yük tepe noktasını atlatır) ele alındı mı?
• Bağımlılık olarak dağıtık önbellek? Paylaşılan önbelleğin bir zaman aşımı ve çöktüğünde tanımlı bir davranışı var mı?
• Gözlemlenebilir mi? İsabet oranı, tahliye, gecikme ve bir yanıtın kökeni/yaşı ölçülüyor mu?
• Geri alınabilir mi? Gerektiğinde önbellek, sistem durmadan kapatılabilir mi?

Bu soruları temiz şekilde cevaplayamayan kişinin elinde bir performans özelliği değil, bakımı için hiçbir planı olmayan ikinci bir doğruluk kaynağı vardır.

Sıkça Sorulan Sorular

Caching, yavaş bir sistemi hızlandırmanın en hızlı yolu değil mi? Yavaşlığı gizlemenin en hızlı yoludur. Bunun iyi olup olmadığı nedene bağlıdır. Neden salt, tekrarlanan okuma yüküyse önbellek doğru cevaptır. Neden eksik bir indeks ya da senkron bir çağrıysa önbellek sorunu konserve eder ve sonradan bulunmasını zorlaştırır. Bu yüzden ölçüm önbellekten önce gelir.

Önbellek invalidasyonu neden bu kadar zordur? Çünkü bir yerde, başka bir yerde bir şeyin değiştiğini bilmeyi gerektirir. Doğrunun değişebileceği her yol kopyayı geçersiz kılmalıdır — ve geride yanlış bir kopya kalması için gözden kaçmış tek bir yazma yolu yeterlidir. Hata o zaman yalnızca ara sıra kendini gösterir ve bu da onu özellikle inatçı kılar.

Global bir ömür belirlemeli miyiz? Hayır. Ömür, belirli bir değerin ne kadar eskimeyi kaldırdığına dair iş alanına yönelik bir ifadedir ve bu veri türünden veri türüne farklıdır. Global bir değer ya hassas veriler için fazla uzun ya da kritik olmayanlar için fazla kısadır — çoğu zaman ikisi birden.

Bir değişiklikte kopyanın üzerine mi yazarız, yoksa onu siler miyiz? Şüphe durumunda sileriz. Eşzamanlılık altında üzerine yazmak bir yarış durumudur: Eşzamanlı iki değişiklik önbelleği kaynakla çelişen bir sıraya sokabilir. Kopyayı kaldırmak bir sonraki okuyucuyu onu taze olarak almaya zorlar ve bu nedenle daha sağlamdır — ek bir ıskalama (cache miss) pahasına.

Dağıtık önbelleğimiz çökerse ne olur? Bu, çökmeden önce cevaplanmış olmalıdır. Önbellek bir ağ bağımlılığıdır: Bir zaman aşımına ve yanıt vermediğinde tanımlı bir davranışa ihtiyaç duyar — genellikle: onu atlayıp kaynakla çalışmaya devam etmek. Önbelleği olmadan duran bir sistem, veritabanını daha az kalıcı bir bağımlılıkla takas etmiş olur.

Yerel yerine dağıtık önbellek ne zaman karşılığını verir? Düğümler arasındaki sapma iş açısından rahatsız ettiğinde ya da cache'lenecek miktar tek tek her süreç için fazla büyüdüğünde. Yerel bir önbellek yeterli olduğu sürece daha iyi seçimdir, çünkü daha basittir ve paylaşılan bir çökme kaynağı getirmez.

İleri okuma

• On yıl sonra hâlâ çalışan yazılım — ikinci bir doğruluk kaynağı neden yazılımın ömrü boyunca değiştirilebilirliği şekillendirir.
• Kuyruk mu, senkron işleme mi ve Asenkron işlemeyi devreye almak — işi istek yolunda yapmama konusundaki ilgili soru.
• Dağıtık sistemlerde idempotency — bir kopyayı kaldırmanın neden üzerine yazmaktan daha sağlam olduğu, tekrarlanabilirliğin aynı disiplinidir.
• Bir mimari ilke olarak observability — ölçmediğiniz bir önbellek bir tahmindir.

Temelini Batunet Engineering Method oluşturur: önce ölçmek, sonra karar vermek; hata durumuna göre tasarlamak; küçük, geri alınabilir adımlarla inşa etmek.

Önbellek ödünç alınmış hızdır. Onu tutarlılıkla geri ödersiniz — tek soru, bunun bilinçli ve planlı mı, yoksa sürpriz şekilde ve bir kesinti anında mı olacağıdır.