Yüksek İstekli Ortamlarda Redis ile Önbellekleme

Bir API saniyede birkaç istek alırken veritabanından aynı kaydı tekrar tekrar okumak büyük sorun yaratmayabilir. Trafik binlerce eşzamanlı isteğe çıktığında ise aynı sorgular connection pool, CPU, disk erişimi ve downstream servisler üzerinde hızla baskı oluşturmaya başlar. On yıllık backend deneyimimde cache kullanımındaki en önemli farkın Redis'i sisteme eklemekten değil, hangi verinin hangi sürede ve hangi tutarlılık koşuluyla saklanacağını doğru belirlemekten geldiğini gördüm. Yüksek İstekli Ortamlarda Redis ile Önbellekleme yaklaşımı bu nedenle yalnızca hızlı bir GET ve SET katmanı kurmak değildir. Bu rehberde cache-aside, write-through, write-behind, TTL, stampede koruması, eviction, Redis Cluster, Sentinel, hot key, big key, invalidation, client-side caching ve production gözlemlenebilirliği gibi konuları birlikte ele alacağız.

Redis ile Önbellekleme Nedir?

Redis ile önbellekleme, sık kullanılan veya üretilmesi pahalı verilerin daha hızlı erişilebilen bir katmanda geçici olarak tutulmasıdır. Uygulama her istekte ana veritabanına gitmek yerine önce Redis üzerinde uygun bir cache kaydı arayabilir. Kayıt bulunduğunda veritabanı sorgusu tamamen atlanır ve yanıt süresi önemli ölçüde düşebilir. Kayıt bulunmazsa veri gerçek kaynaktan okunur ve sonraki istekler için cache'e yerleştirilebilir. Bu model özellikle tekrar oranı yüksek okuma trafiğinde database kapasitesini daha değerli işlemler için korumaya yardımcı olur.

Cache Nedir?

Cache, başka bir kaynaktan tekrar üretilebilen verinin erişimi daha ucuz bir katmanda geçici kopyasının tutulmasıdır. Amaç verinin gerçek sahibini değiştirmek değil, sık gerçekleşen okumaların maliyetini azaltmaktır. Cache kaydı süresiz doğru kabul edilmemeli ve freshness politikası açıkça belirlenmelidir. Cache kaybolduğunda sistem veriyi kaynağından yeniden oluşturabiliyorsa klasik cache modeli daha güvenli çalışır. Bu nedenle cache tasarımında ilk sorum her zaman “Bu kayıt silinirse sistem onu güvenilir biçimde yeniden üretebilir mi?” olur.

Redis Nedir?

Redis düşük gecikmeli veri erişimi için bellekte çalışan veri yapıları ve veri işleme yetenekleri sunan bir veri platformudur. String, hash, list, set, sorted set, stream ve çeşitli ek veri yapıları farklı kullanım desenlerine hizmet eder. Cache senaryolarında en temel ihtiyaç key üzerinden hızlı veri okuma ve kontrollü expiration yönetimidir. Redis ayrıca replication, high availability ve cluster topolojileriyle tek process sınırının ötesinde çalışabilir. Bununla birlikte Redis'i hızlı olduğu için her veri probleminin çözümü olarak görmek yerine kullanım amacını açık biçimde tanımlamak gerekir.

Redis Neden Cache Olarak Kullanılır?

Redis'in bellekte çalışan erişim modeli disk tabanlı ana veritabanına yapılan birçok tekrar sorgusundan daha düşük gecikme sağlayabilir. TTL desteği cache kayıtlarının belirli süre sonunda otomatik olarak geçersiz hale gelmesini kolaylaştırır. Eviction policy seçenekleri sınırlı memory altında hangi kayıtların çıkarılacağını yönetmeye yardımcı olur. Network üzerinden birden fazla application instance tarafından paylaşılabildiği için local process cache'e göre ortak bir cache katmanı oluşturur. Veri yapıları, atomic command'lar ve cluster desteği de basit key-value cache'in ötesindeki yüksek trafik ihtiyaçlarını karşılayabilir.

In-Memory Veri Erişiminin Avantajları

Bellekten veri erişimi disk veya uzak database sorgusuna göre çok daha düşük latency sağlayabilir. Özellikle küçük payload ve kısa Redis RTT değerlerinde cache hit kullanıcı isteğinin toplam süresini belirgin biçimde azaltır. Database tarafında query parsing, execution, buffer erişimi ve connection kullanımı gibi işler de ortadan kalkabilir. Aynı popüler nesne saniyede binlerce kez okunuyorsa bu kazanç toplam kaynak kullanımında daha belirgin hale gelir. Yine de uygulama ile Redis arasındaki network mesafesi yüksekse in-memory olmanın tek başına düşük uçtan uca gecikme garantisi vermediğini unutmamak gerekir.

Redis Cache ile Database Arasındaki Rol Farkı

Ana database çoğu uygulamada verinin güvenilir source of truth katmanıdır. Redis cache ise bu verinin tekrar üretilebilen geçici bir temsilini taşır. Cache kaybında veri bütünlüğü bozulmamalı, yalnızca origin üzerinde geçici olarak daha fazla yük oluşmalıdır. Write-behind veya session gibi farklı modeller Redis'e daha kritik rol verebilir ve dayanıklılık gereksinimini artırabilir. Bu yüzden her Redis key'i için “cache mi, durable state mi?” sorusunun cevabını mimari dokümantasyonda açıkça belirtmek gerekir.

Yüksek İstekli Bir Sistemde Cache Neden Gereklidir?

Yüksek trafikli sistemlerde aynı verinin tekrar tekrar üretilmesi kaynakların verimsiz kullanılmasına yol açabilir. Cache bu tekrarı azaltarak database, uygulama sunucusu ve downstream servisler üzerindeki baskıyı paylaşır. Özellikle read-heavy API'lerde origin sorgularının önemli bölümü cache hit sayesinde tamamen ortadan kaldırılabilir. Bunun yanında trafik artışı sırasında origin'in kapasitesini aşmasını geciktiren bir koruma katmanı oluşur. Fakat cache yanlış tasarlanırsa stampede veya avalanche sırasında korumak istediği database üzerinde daha büyük ani yük oluşturabileceği için resilience tasarımı en az hız kadar önemlidir.

Tekrarlanan Database Query'leri

Aynı ürün, kategori veya configuration kaydı çok sayıda kullanıcı tarafından tekrar tekrar sorgulanabilir. Database her seferinde aynı sonucu üretmek için CPU ve buffer kaynaklarını yeniden kullanır. Redis sonucu birkaç saniye veya dakika sakladığında bu sorguların önemli kısmı origin'e ulaşmaz. En büyük kazancı genellikle yüksek tekrar oranına sahip query'lerde görüyorum. Cache candidate analizi yaparken yalnızca sorgunun pahalı olup olmadığına değil, aynı input ile ne kadar sık tekrarlandığına da bakmak gerekir.

Database Connection Pool Saturation

Application instance'ları database bağlantılarını genellikle sınırlı bir pool üzerinden kullanır. Trafik arttığında bütün bağlantılar meşgul olabilir ve yeni request'ler connection beklemeye başlar. Cache hit database'e hiç bağlantı gerektirmediği için pool üzerindeki eşzamanlı talebi azaltabilir. Bu durum özellikle kısa fakat yüksek frekanslı read query'lerinde ciddi rahatlama sağlar. Cache kurduktan sonra yalnızca Redis hit rate değil database pool wait time metriğini de izlemek cache'in gerçek sistem etkisini görmeye yardımcı olur.

CPU ve I/O Baskısı

Pahalı join, aggregation veya geniş scan yapan sorgular database CPU ve I/O kapasitesini tüketebilir. Sonuç sık değişmiyorsa aynı hesaplamayı her istekte yeniden yapmak gereksizdir. Redis bu sonucu belirlenen süre boyunca saklayarak origin computation sayısını düşürür. Database kaynakları daha kritik ve cache'lenemeyen işlemler için kullanılabilir. Cache'in faydasını ölçerken origin CPU ve physical read değerlerindeki değişime bakmak yalnızca kullanıcı latency'sine bakmaktan daha kapsamlı sonuç verir.

API Latency Artışı

Database yoğunlaştıkça normalde hızlı çalışan query'lerin tail latency değerleri yükselmeye başlayabilir. Bir endpoint birden fazla database ve downstream çağrısı yapıyorsa bu gecikmeler birbirine eklenir. Cache hit bazı network ve query adımlarını tamamen ortadan kaldırabilir. Özellikle p95 ve p99 latency kullanıcıların en kötü deneyimlerini anlamada önemlidir. Redis ile yüksek istek altında önbellekleme performansı nasıl artırılır sorusunun cevabı bu nedenle yalnızca ortalama Redis latency'sine değil uçtan uca endpoint latency'sine bakmayı gerektirir.

Trafik Spike'ları

Kampanya, bildirim veya viral içerik kısa sürede normal trafiğin katları kadar istek oluşturabilir. Cache popüler verileri origin'e gitmeden sunarak spike'ın önemli kısmını emebilir. Fakat aynı anda expire olan popüler key'ler cache avantajını tersine çevirebilir. TTL jitter, stale serving ve request coalescing gibi teknikler bu yüzden spike tasarımının doğal parçalarıdır. Peak trafik kapasite testleri cache sıcak ve cache soğuk senaryoları ayrı ayrı içermelidir.

Downstream Service Koruması

Uygulama yanıt üretmek için başka servislerden reference veya catalog verisi çekiyor olabilir. Her incoming request'i downstream servise yansıtmak zincirleme saturation riskini artırır. Redis kısa süreli response cache ile bu servise giden QPS'i azaltabilir. Downstream servis hata verdiğinde stale-if-error politikası belirli veri sınıflarında geçici dayanıklılık da sağlayabilir. Bu yaklaşım service dependency'yi tamamen ortadan kaldırmaz fakat kontrollü şekilde daha az baskı altında tutar.

Hangi Veriler Cache'lenmelidir?

İyi cache adayı sık okunan, üretimi görece pahalı ve belirli süre eski kalması kabul edilebilir veridir. Aynı key'in tekrar kullanılma ihtimali yüksek olmalıdır. Origin query ucuz olsa bile milyonlarca kez tekrarlanıyorsa cache yine anlamlı olabilir. Buna karşılık her veriyi cache'e almak memory tüketimini büyütür ve hit oranını düşürebilir. Veri sınıflarını erişim frekansı, update sıklığı, payload boyutu, origin maliyeti ve staleness toleransına göre sınıflandırmak daha doğru sonuç verir.

Sık Okunan Veriler

Bir key saniyede binlerce kez okunuyor ancak dakikada bir değişiyorsa ideal cache adaylarından biridir. Product detail, navigation configuration veya public profile örnekleri bu gruba girebilir. Hot key riski oluşuyorsa L1 local cache veya client-side caching gibi ek katmanlar değerlendirilebilir. TTL yalnızca veri değişim süresine göre değil traffic concentration'a göre de seçilmelidir. Sık okunan veride küçük bir hit-rate artışı bile origin QPS üzerinde büyük mutlak fark yaratabilir.

Pahalı Database Query Sonuçları

Büyük aggregation, çoklu join veya hesaplanan dashboard sonucu her request'te yeniden üretilmemelidir. Sonuç birkaç saniye eski kalabiliyorsa Redis'e snapshot şeklinde yazılabilir. Cache key query'nin sonucu değiştiren bütün önemli parametreleri içermelidir. Aksi durumda farklı kullanıcı veya filtreler aynı yanlış sonucu paylaşabilir. Pahalı query cache'inde miss penalty yüksek olduğu için stampede koruması özellikle önemlidir.

API Response'ları

Public veya authorization açısından güvenli API yanıtları endpoint bazında cache'lenebilir. Query parameters key'e deterministic biçimde eklenmelidir. Kullanıcıya özel response cache'leniyorsa user veya permission context key'e dahil edilmelidir. Response içindeki kısa ömürlü alanlar bütün payload TTL'ini gereksiz azaltabilir ve ayrı cache segmentleri düşünülebilir. Cache poisoning riskine karşı key üretimi kontrolsüz client input'un doğrudan birleştirilmesine bırakılmamalıdır.

Configuration ve Reference Data

Country list, feature configuration veya sabit lookup değerleri sık okunup seyrek değişebilir. Bu veriler uzun TTL ve event-driven invalidation ile iyi cache performansı sağlar. Uygulama her request'te database'e configuration query göndermek zorunda kalmaz. Çok küçük ve process-wide değerler L1 application cache için de uygun olabilir. Değişikliklerin ne kadar hızlı yayılması gerektiği configuration türüne göre ayrıca belirlenmelidir.

Product Catalog

Product catalog genellikle yüksek read trafiği ve tekrar oranı taşır. Ürün adı, açıklama ve public metadata saniyelik staleness toleransına sahip olabilir. Fiyat veya stok ise daha farklı freshness kurallarına ihtiyaç duyabilir. Tek ürün object'i içinde her alanı aynı TTL'e bağlamak bu nedenle bazen uygun değildir. Catalog cache tasarımında content, pricing ve inventory verilerini ayrı freshness sınıfları olarak ele almak daha esnek olur.

Kullanıcı Profilleri

Kullanıcı profilinin sık okunan public veya preference alanları cache'e alınabilir. Key tenant ve user identity'yi doğru biçimde taşımalıdır. Permission veya security-sensitive state için kabul edilen staleness çok daha kısa olabilir. Profile update sonrasında explicit invalidation uygulanabilir. Kişisel veriler cache'e yazılıyorsa encryption, access control ve retention politikaları ana database kadar dikkatle uygulanmalıdır.

Hesaplanması Pahalı Sonuçlar

Recommendation, report summary veya dış servisten oluşturulan birleşik sonuç pahalı olabilir. Sonucu uygun TTL ile cache'lemek CPU ve downstream maliyetini düşürür. Input set'i değiştiğinde version veya event üzerinden invalidation yapılabilir. Sonucun personalization düzeyi key cardinality'yi etkiler. Her kullanıcıya benzersiz result üretiliyorsa tekrar ihtimali düşük olabilir ve cache ROI ayrıca ölçülmelidir.

Hangi Veriler Cache'lenmemelidir?

Cache kullanımında en değerli karar bazen bir veriyi hiç cache'lememektir. Çok hızlı değişen veya kesin freshness gerektiren data için invalidation maliyeti cache kazancından yüksek olabilir. Tek sefer okunan yüksek-cardinality kayıtlar memory'de yer kaplayıp tekrar kullanılmadan evict olabilir. Çok ucuz origin query'lerinde network üzerinden Redis'e gitmek bile daha pahalı hale gelebilir. Cache candidate seçimi bu nedenle teorik hız beklentisi yerine gerçek hit ihtimali ve toplam sistem maliyeti üzerinden yapılmalıdır.

Çok Hızlı Değişen Veriler

Saniyede yüzlerce kez değişen bir counter'ı cache'e koymak sürekli invalidation veya write yükü oluşturabilir. Redis counter'ın kendisi source of truth olarak tasarlanmışsa bu başka bir kullanım modelidir. Burada söz konusu olan database değerinin cache kopyasıysa update frequency ciddi maliyet yaratır. Cache hit elde edilmeden key tekrar stale hale gelebilir. Böyle data için doğrudan optimized origin query veya farklı data model daha doğru olabilir.

Cache Hit İhtimali Çok Düşük Veriler

Bir key yalnızca bir kez okunuyor ve sonra hiç kullanılmıyorsa cache'e yazılması ekstra network ve memory maliyeti yaratır. Büyük export veya one-time report sonuçlarında bu durum sık görülür. Hit rate toplam ortalamada yüksek görünse bile belirli namespace düşük fayda sağlayabilir. Namespace bazlı hit/miss ölçümü bu sorunu ortaya çıkarır. Admission policy ile yalnızca tekrar kullanım sinyali güçlü verilerin cache'e alınması bazı sistemlerde daha etkili olur.

Hassas Tutarlılık Gerektiren Veriler

Ödeme bakiyesi, yetki kararı veya kritik transaction state gibi veriler eski kaldığında ciddi sonuçlar doğurabilir. Bu veriler kesinlikle cache'lenemez demek doğru değildir, ancak tutarlılık protokolü daha güçlü olmalıdır. Permission cache çok kısa TTL ve explicit invalidation ile kullanılabilir. Para hareketi gibi işlemlerde source of truth her zaman authoritative database veya ledger olmalıdır. Cache freshness garantisi iş gereksinimini karşılamıyorsa performans uğruna güvenilirlikten vazgeçilmemelidir.

Cache Maliyetinin Origin Query'den Fazla Olduğu Durumlar

Aynı process memory'sinde bulunan küçük lookup için uzak Redis çağrısı local hesaplamadan daha pahalı olabilir. Basit indexed database query de düşük trafik altında yeterince ucuz olabilir. Serialization ve deserialization payload büyüdükçe cache latency'sine eklenir. Cache invalidation ve operasyon yönetimi de mühendislik maliyetidir. Bu nedenle cache ancak ölçülen bottleneck'i çözdüğünde sisteme eklenmelidir.

Yüksek Trafik İçin Temel Redis Cache Mimarisi

Temel dağıtık cache mimarisinde client isteği load balancer üzerinden application instance'a gelir. Application önce Redis'te ilgili key'i kontrol eder. Cache hit varsa response hızlı biçimde üretilir. Cache miss durumunda primary database veya ilgili origin servis çağrılır ve sonuç Redis'e belirli TTL ile yazılır. Bu basit akış production'da timeout, retry, stampede protection ve observability eklenmeden tamamlanmış sayılmamalıdır.

Client

Client web tarayıcı, mobil uygulama veya başka bir service olabilir. Client genellikle Redis'e doğrudan bağlanmamalıdır. Cache politikası application backend tarafından yönetilir ve authorization kontrolü origin seviyesinde korunur. Public content için client'a yakın CDN ayrı cache katmanı sağlayabilir. Böylece Redis private application data katmanında kalırken edge cache internet trafiğinin bir bölümünü daha erken karşılayabilir.

Load Balancer

Load balancer request'leri birden fazla application instance arasında dağıtır. Dağıtık Redis cache bütün instance'ların aynı cache state'ine erişmesini sağlar. Local L1 cache kullanılırsa her instance'ın kendi kopyası oluşur ve invalidation daha önemli hale gelir. Autoscaling sırasında yeni instance'lar Redis üzerinden cache'e hemen erişebilir. Connection sayısı application instance sayısıyla büyüdüğü için Redis connection capacity load balancer arkasındaki toplam replica sayısına göre planlanmalıdır.

Application Instances

Application cache key oluşturma, serialization, timeout ve fallback politikasını uygular. Her request için yeni Redis connection açmak yerine client connection'ları yeniden kullanılmalıdır. Request coalescing aynı instance içindeki duplicate miss'leri tek origin çağrısına indirebilir. Redis failure durumunda bütün application instance'ların aynı anda database'e dönmesi yeni overload riski yaratır. Bu nedenle fallback path rate limit ve load shedding ile korunmalıdır.

Redis

Redis application ile origin arasında düşük gecikmeli distributed cache görevi görür. Memory limiti ve eviction policy cache workload'una uygun biçimde yapılandırılır. High availability için Sentinel veya horizontal capacity için Redis Cluster gibi topolojiler değerlendirilebilir. Redis latency yalnızca server processing değil network RTT ile birlikte ölçülmelidir. Cache sunucusu primary database'den bağımsız failure domain üzerinde tutulursa ortak altyapı arızalarının etkisi azaltılabilir.

Primary Database

Primary database çoğu cache-aside sistemde gerçek source of truth olarak kalır. Redis key silindiğinde uygulama gerekli veriyi buradan yeniden oluşturur. Cache sayesinde database'in normal read QPS'i önemli ölçüde düşebilir. Ancak cold-cache veya outage sırasında bütün read trafiğini karşılayabilecek kapasite veya kontrollü degradation planı bulunmalıdır. Cache'i database kapasitesizliğini tamamen gizleyen tek koruma katmanı yapmak tehlikelidir.

Cache Hit Akışı

Application deterministic cache key'i oluşturur ve Redis'e okuma yapar. Değer bulunursa deserialize edilerek kullanıcıya dönülür. Origin database'e bağlantı açılması gerekmez. Metrics tarafında hit sayısı ve cache latency kaydedilir. Soft TTL kullanılıyorsa değer eski pencereye girmiş olabilir ve response sunulurken background refresh ayrıca tetiklenebilir.

Cache Miss Akışı

Redis key'i bulamazsa application origin'e gider. Sonuç başarıyla alındığında serialization yapılarak TTL ile cache'e yazılır. Aynı key için çok sayıda request geliyorsa tek origin çağrısı yapmak için single-flight veya lock kullanılabilir. Origin hata verirse cache'e hata sonucu yazılıp yazılmayacağı veri türüne göre belirlenir. Negative cache özellikle gerçekten bulunmayan kaynakların tekrar tekrar database'e gitmesini engeller.

Cache Hit ve Cache Miss Nedir?

Cache hit istenen verinin cache içinde bulunmasını, miss ise cache'te kullanılabilir kayıt olmamasını ifade eder. Bütün miss'ler aynı nedenle oluşmaz. İlk kez istenen key cold miss, süresi dolmuş key expired miss, memory baskısıyla çıkarılmış key eviction kaynaklı miss olabilir. Bu ayrım cache tuning için önemlidir. Sadece toplam miss sayısını izlemek hangi problemin çözülmesi gerektiğini söylemez.

Cache Hit

Cache hit uygulamanın ihtiyaç duyduğu değeri Redis'ten bulduğu durumdur. Hit durumunda origin query atlanır. Kullanıcı latency'si çoğunlukla Redis RTT, serialization ve uygulama processing süresine iner. Hit'in gerçekten yararlı olması için cache değerinin doğru ve kabul edilen freshness sınırında olması gerekir. Yanlış veya aşırı stale veri sunan yüzde 99 hit rate başarılı bir cache sistemi anlamına gelmez.

Cache Miss

Cache miss key bulunmadığında veya kayıt kullanılamaz olduğunda gerçekleşir. Miss sonrası origin çağrısının maliyeti cache sisteminin önemli performans parçasıdır. Çok pahalı origin query'lerinde küçük miss spike bile ciddi etki yaratabilir. Miss reason etiketleri monitoring açısından yararlıdır. Cache hit rate kadar miss penalty'nin de ölçülmesi bu nedenle gerekir.

Cold Miss

Cold miss key'in daha önce cache'e hiç yazılmamış olmasıdır. Deployment sonrası yeni versioned namespace bu durumu kitlesel biçimde oluşturabilir. Yeni traffic pattern de daha önce kullanılmamış key'leri hızla cache'e getirebilir. Cache warming popüler key'ler için cold miss miktarını azaltabilir. Bütün dataset'i preload etmek ise memory ve origin yükünü gereksiz büyütebileceği için yalnızca tahmin edilen sıcak set hedeflenmelidir.

Expired Key Miss

Key TTL sonunda expire olduğunda sonraki request miss yaşar. Tek key için normal olan bu davranış binlerce key aynı anda expire olduğunda avalanche riskine dönüşür. Popüler key expire olduğunda aynı anda yüzlerce origin request oluşabilir. Jitter ve refresh-ahead bu yoğunlaşmayı dağıtır. Expired miss oranının deployment veya belirli saatlerde yükselmesi TTL tasarımının incelenmesi gerektiğini gösterir.

Eviction Kaynaklı Miss

Redis memory limitine ulaştığında seçilen eviction policy bazı key'leri çıkarabilir. Sonraki request bu key için miss olur. Eviction rate yükseliyorsa working set memory'ye sığmıyor olabilir. Yanlış policy hot key'leri gereğinden erken çıkarabilir. Cache thrashing durumunda sürekli evict ve repopulate döngüsü oluştuğu için memory kapasitesi ile key admission politikası yeniden değerlendirilmelidir.

Origin Fetch

Miss sonrası database veya başka servis üzerinden yapılan gerçek veri okumasına origin fetch diyebiliriz. Bu işlem cache hit'e kıyasla çok daha pahalı olabilir. Origin latency, connection pool wait ve error rate ayrıca ölçülmelidir. Stampede sırasında origin fetch sayısı cache miss sayısıyla bire bir artmamalıdır. Coalescing uygulandığında onlarca miss aynı tek fetch sonucunu paylaşabilir.

Cache Hit Rate Nasıl Hesaplanır?

Cache hit rate temel olarak başarılı hit sayısının toplam cache lookup sayısına oranıdır. Basit formül yararlı olsa da tek başına cache kalitesini açıklamaz. Düşük maliyetli key'lerde çok yüksek hit oranı, pahalı query'lerde düşük hit oranını gizleyebilir. Namespace ve endpoint bazında ölçüm daha anlamlıdır. Ayrıca hit oranının origin QPS'i gerçekten ne kadar azalttığı ayrı metrik olarak izlenmelidir.

Hit

Hit Redis'ten kullanılabilir değer dönen lookup'tır. Application cache wrapper her hit'i merkezi metric olarak sayabilir. L1 local cache ve L2 Redis kullanılıyorsa katmanlar ayrı ölçülmelidir. Aksi halde Redis hit rate düşük görünürken toplam cache efficiency yüksek olabilir. Hit latency distribution da value size ve network path problemlerini anlamaya yardım eder.

Miss

Miss cache lookup'ın value üretemediği durumdur. Miss reason cold, expired, evicted veya negative-cache expiry şeklinde sınıflandırılabilir. Origin fetch başarılı olsa bile Redis write başarısız olabilir ve sonraki request tekrar miss yaşar. Bu durum populate failure metriğiyle görünür olmalıdır. Sadece keyspace miss counter'ı application-level semantiğin tamamını göstermeyebilir.

Hit Ratio Formülü

Temel formül hit / (hit + miss) şeklindedir. Örneğin 900 hit ve 100 miss yüzde 90 hit ratio üretir. Bu oran belirli zaman aralığı ve namespace için hesaplanmalıdır. Çok farklı workload'ları tek global değerde birleştirmek yanıltıcı olabilir. İş açısından kritik endpoint'ler için ayrı target hit oranı belirlemek daha sağlıklıdır.

Hit Rate'in İş Yüküne Göre Yorumlanması

Product catalog gibi yüksek tekrar oranlı veride yüzde 95 üzeri hedef makul olabilir. Personalized veya yüksek-cardinality feed cache'inde yüzde 50 bile ciddi origin tasarrufu sağlayabilir. Negative caching bulunan sistemde “not found” hit'leri ayrıca sınıflandırılabilir. Cache hit'in kaç milisaniye ve kaç database query tasarrufu sağladığı önemlidir. Aynı oran farklı origin maliyetlerinde tamamen farklı business değeri üretir.

Yüksek Hit Rate Her Zaman İyi midir?

Hayır, yüksek hit rate yanlış veya gereksiz veri cache'leyerek de elde edilebilir. Çok uzun TTL stale content riskini artırabilir. Cache değerleri origin query'den daha pahalı serialization taşıyorsa hit bile yavaş olabilir. Ayrıca yüzde 99 hit oranında kalan yüzde 1 miss çok yüksek trafik altında origin'i hâlâ zorlayabilir. Hit rate bu nedenle latency, freshness ve origin offload ile birlikte değerlendirilmelidir.

Cache Effectiveness Nasıl Ölçülür?

Cache effectiveness kullanıcı latency'si ve origin kaynak tasarrufunun birlikte ölçülmesidir. Hit rate bunun yalnızca bir parçasıdır. Database query sayısı, origin QPS, p95 ve p99 latency, miss penalty ve Redis altyapı maliyeti karşılaştırılmalıdır. Cache yüzünden eklenen serialization CPU'su ve invalidation operasyonu da hesaba katılmalıdır. Başarılı cache daha yüksek hit sayısından çok sistemin toplam kapasitesini ve dayanıklılığını iyileştirir.

Database Query Azalması

Cache kurulmadan önce ve sonra aynı trafik seviyesinde database query count karşılaştırılabilir. Read query sayısının düşmesi connection pool ve CPU üzerinde doğrudan etki yaratır. Write query sayısında artış olmamalıdır, ancak invalidation için ek işlemler bulunabilir. Endpoint bazlı attribution hangi cache'in en fazla kazanç sağladığını gösterir. Query count azalırken database CPU değişmiyorsa başka pahalı workload'lar araştırılmalıdır.

Origin QPS Reduction

Origin QPS cache sayesinde kaç isteğin backend kaynağına ulaşmadığını gösterir. Database dışındaki pricing veya catalog servisi için de aynı metrik kullanılabilir. Yüzde 80 offload saniyede 10 bin request alan endpoint'te çok büyük kapasite farkı yaratır. Peak saatlerdeki reduction ayrıca incelenmelidir. Origin'in cold-cache sırasında ne kadar yük gördüğü resilience testinde doğrulanmalıdır.

P95/P99 Latency

Cache hit ortalamayı düşürürken miss veya failover tail latency'yi yüksek bırakabilir. p95 ve p99 bu kötü deneyimleri görünür yapar. Redis timeout ayarı çok yüksekse cache arızasında her request gereksiz bekleyebilir. Short timeout ve kontrollü fallback tail'i iyileştirebilir. Latency metriği hit ve miss olarak ayrı etiketlenirse hangi path'in sorumlu olduğu kolay anlaşılır.

Cache Hit Rate

Hit rate tekrar kullanım verimliliğini gösterir. Namespace bazında düşük oranlı cache'ler cleanup adayı olabilir. Hit oranı eviction spike ile aniden düşüyorsa memory pressure araştırılır. Deployment sonrası versioned keys cold miss üretebilir. Trend analizi yalnızca anlık yüzde değerinden daha fazla bilgi verir.

Miss Penalty

Miss penalty cache bulunmadığında kullanıcıya eklenen origin maliyetidir. Pahalı SQL veya remote API fetch bu değeri yükseltir. Cache stampede sırasında aynı penalty birçok request tarafından paralel ödenebilir. Single-flight bunu azaltır. En yüksek miss penalty taşıyan key'ler refresh-ahead ve stale serving için öncelikli adaylardır.

Redis Maliyeti vs Database Tasarrufu

Redis memory ve network kapasitesi de altyapı maliyetidir. Büyük cache cluster kurup yalnızca ucuz query'leri offload etmek ekonomik olmayabilir. Database compute tasarrufu, Redis maliyeti ve mühendislik operasyonu birlikte değerlendirilmelidir. Managed hizmet veya self-hosted model bu dengeyi değiştirebilir. Cache ROI periyodik olarak gerçek traffic ve cloud cost verileriyle tekrar hesaplanmalıdır.

Cache-Aside Pattern Nedir?

Cache-aside modelinde uygulama cache ile database arasındaki akışı kendisi yönetir. Önce Redis kontrol edilir, değer yoksa origin'den okunur ve cache'e yazılır. Database write olduğunda cache genellikle silinir veya güncellenir. Model basit, esnek ve farklı backend dilleriyle kolay uygulanabilir olduğu için yaygındır. Redis cache aside write through ve write behind stratejileri karşılaştırması yapılırken cache-aside çoğu read-heavy sistem için iyi başlangıç noktasıdır.

Önce Redis'i Kontrol Etme

Application request'ten deterministic key üretir. Redis GET veya ilgili data type komutu çalıştırılır. Timeout kısa tutulmalıdır, çünkü cache performans için eklenmiştir ve request'i uzun süre bekletmemelidir. Değer varsa origin çağrısına ihtiyaç kalmaz. Redis hata verirse sistemin fallback policy'sine göre database'e kontrollü geçiş yapılır.

Cache Hit

Hit durumunda value deserialize edilir ve response için kullanılır. Freshness metadata soft TTL için ayrıca kontrol edilebilir. L1 cache varsa Redis'e bile gitmeden önce local hit oluşabilir. Cache hit path uygulamanın en hızlı ve en sık çalışan kod yollarından biri olduğu için gereksiz logging veya ağır transformation içermemelidir. Performans testleri yalnızca Redis server değil bu tam application path'i ölçmelidir.

Cache Miss

Miss durumunda origin read başlatılır. Aynı anda gelen duplicate miss'ler database'e paralel gitmemelidir. Instance-local single-flight en azından aynı process içindeki concurrency'yi azaltır. Distributed environment'ta lock veya stale response gibi ek yöntem gerekir. Miss oranı küçük olsa bile popüler key üzerinde eşzamanlı oluşuyorsa etkisi büyük olabilir.

Database'den Okuma

Origin database authoritative veriyi döndürür. Query mümkün olduğunca optimize edilmiş olmalıdır, çünkü cache sistemi hiçbir zaman yüzde yüz hit garantisi vermez. Cache failure veya cold start sırasında bu query çok daha yüksek QPS görebilir. Database connection pool buna göre korunmalıdır. Origin fetch fail olursa hatalı veya yarım veri cache'e yazılmamalıdır.

Redis'e Yazma

Database sonucu başarılı olduktan sonra cache'e serialize edilerek yazılır. Cache write başarısızsa çoğu cache-aside sistem kullanıcı request'ini yine başarılı döndürebilir. Bu durumda sonraki request yeniden origin'e gideceği için populate failure metriği önemlidir. Büyük value yazımı Redis network ve memory üzerinde maliyet oluşturur. Write path'e gereksiz distributed transaction eklemek basit cache modelinin avantajını kaybettirebilir.

TTL Ekleme

Cache value genellikle expiration ile birlikte yazılmalıdır. TTL verinin ne kadar eski kalabileceğini sınırlar. Aynı veri grubundaki key'lere küçük random jitter eklemek toplu expiration riskini azaltır. TTL business freshness requirement'ından türetilmelidir. “Her şeye beş dakika” gibi tek global değer hem stale riskini hem düşük cache verimini artırabilir.

Cache-Aside Ne Zaman Kullanılmalıdır?

Cache-aside özellikle read-heavy ve kaynak veriden tekrar üretilebilen içeriklerde uygundur. Uygulama cache population ve invalidation üzerinde açık kontrole sahip olur. Redis geçici olarak çalışmazsa origin üzerinden devam etmek daha kolaydır. Bunun karşılığında miss sırasında kullanıcı origin latency'sini doğrudan yaşar. Hot key'lerde stampede koruması eklenmezse cache-aside'ın basit miss davranışı yüksek trafik altında risk oluşturur.

Read-Heavy Sistemler

Read sayısının write sayısından çok yüksek olduğu sistemlerde cache hit büyük tasarruf yaratır. Aynı value birçok kullanıcı tarafından tekrar okunuyorsa ROI yükselir. Write sırasında cache delete edilip sonraki read'in yeniden populate etmesi basit ve güvenilir pattern sağlar. Read-after-write freshness gerekiyorsa writer response doğrudan yeni değeri kullanabilir. Cache dışındaki source of truth korunmaya devam eder.

Yüksek Trafikli API'ler

Yüksek trafikli uygulamalarda Redis cache nasıl kullanılır sorusunda cache-aside çoğu zaman ilk uygulanacak modellerden biridir. Endpoint'in input parametreleri doğru key'e dönüştürülür ve response belirli süre saklanır. Public ve user-specific response'lar farklı namespace kullanmalıdır. Stampede ve TTL jitter daha ilk tasarımda eklenmelidir. Cache hit rate ile origin offload birlikte ölçülerek hangi endpoint'lerin gerçekten değer sağladığı görülmelidir.

E-Ticaret

Product detail ve category verileri cache-aside için güçlü adaylardır. Pricing ve inventory aynı product object'inden farklı TTL isteyebilir. Kampanya başladığında event-driven invalidation uygulanabilir. Popular product key hot key haline gelebilir ve local L1 katmanı gerekebilir. Checkout sırasında kesin stok kontrolü yine authoritative inventory kaynağından yapılmalıdır.

Microservices

Bir service başka service'in reference verisini sürekli okuyorsa Redis cache downstream QPS'i azaltabilir. Cache ownership verinin sahibi olan service veya consumer tarafında açıkça belirlenmelidir. Cross-service invalidation event ile yapılabilir. Shared cache key'e birden fazla service'in kontrolsüz yazması contract sorunları yaratır. Her service kendi namespace ve schema version'ını sahiplenirse deployment bağımsızlığı daha iyi korunur.

Pahalı SQL Query'leri

Aggregation veya complex join sonucu yüksek hit ihtimali taşıyorsa cache-aside önemli CPU tasarrufu sağlar. Query parametrelerinin tamamı cache key içinde canonical biçimde temsil edilmelidir. Sonuç seti çok büyükse tüm payload yerine daha küçük summary cache'lemek daha verimli olabilir. Database index tuning yine yapılmalıdır, çünkü miss sırasında query çalışmaya devam eder. Cache kötü SQL'in kalıcı çözümü değil, tekrar maliyetini azaltan tamamlayıcı katmandır.

Read-Through Caching Nedir?

Read-through modelinde application doğrudan cache abstraction'ından veri ister ve cache katmanı miss durumunda origin'i yükleyen mekanizmayı kendisi çalıştırır. Böylece loader mantığı application business code'undan ayrılabilir. Redis tek başına bütün uygulamalar için otomatik relational database loader sağlamaz, bu davranış genellikle library veya platform katmanında kurulur. Cache-aside ile temel veri akışı benzerdir fakat sorumluluk farklı yerde bulunur. Standardized data access layer olan kurumlarda bu yaklaşım tekrar eden kodu azaltabilir.

Cache Loader

Cache loader key bulunmadığında hangi origin kaynağından veri alınacağını bilir. Database repository veya remote service çağrısı loader içinde olabilir. Loader idempotent ve timeout kontrollü olmalıdır. Duplicate miss'lerin aynı loader'ı paralel çalıştırmasını önlemek için coalescing eklenebilir. Loader error durumunda cache'e yanlış fallback value yazılmamalıdır.

Application Complexity

Read-through abstraction business code'daki cache kontrolünü azaltır. Developer yalnızca data accessor çağırır. Ancak abstraction cache behavior'ını gizlerse debugging zorlaşabilir. Hit, miss ve origin fetch trace'leri görünür olmalıdır. TTL ve invalidation configuration domain owner tarafından anlaşılabilir şekilde dışarı açılmalıdır.

Cache-Aside ile Farkı

Cache-aside'da application açık biçimde önce cache sonra origin akışını yazar. Read-through'da aynı sorumluluk cache veya data-access abstraction tarafından üstlenilir. Performance semantics benzer olabilir. Fark daha çok ownership ve implementation boundary'sidir. Distributed stampede problemi iki modelde de ayrıca çözülmelidir.

Hangi Durumlarda Kullanılır?

Birçok service aynı data access pattern'ini tekrar ediyorsa read-through yardımcı olabilir. Platform ekibi ortak cache library sunabilir. Loader ve TTL policy standardize edilir. Çok özel business logic bulunan query'lerde abstraction gereksiz soyutlama yaratabilir. Kullanım kapsamı basit ve tekrar eden access pattern'leriyle sınırlandırıldığında bakım kolaylaşır.

Write-Through Caching Nedir?

Write-through modelinde değişiklik cache ve authoritative storage ile senkron biçimde ele alınır. Amaç write tamamlandıktan hemen sonra cache'in yeni değeri taşımasıdır. Read-after-write freshness yüksek olur. Bunun karşılığında write path'e ek Redis işlemi ve dual-write failure senaryosu eklenir. Transaction sınırı iki sistemi atomik biçimde kapsamadığında consistency stratejisi açıkça tasarlanmalıdır.

Database + Cache Write

Application database'e yeni state'i yazar ve cache'i de aynı mutation akışında günceller. Hangi işlemin önce yapıldığı failure semantics'i değiştirir. Database başarılı, cache başarısız olursa stale cache kalabilir. Cache başarılı, database başarısız olursa daha tehlikeli false state oluşabilir. Source of truth database ise çoğu durumda database commit sonrası cache update tercih edilir.

Read-After-Write Freshness

Cache yeni value ile güncellendiği için mutation sonrası read çoğunlukla güncel state görür. Bu behavior user profile veya configuration gibi alanlarda faydalıdır. Concurrent writer'lar update sırasını bozabilir. Version number veya compare-and-set benzeri teknikler stale overwrite riskini azaltabilir. Read-after-write garantisi yalnızca cache update başarılı olduğunda geçerlidir.

Write Latency

Write request database yanında Redis network çağrısını da bekleyebilir. Bu durum write latency'sini artırır. Pipeline veya transaction abstraction her zaman iki farklı sistemi atomik yapmaz. Cache failure yüzünden business write'ın başarısız sayılıp sayılmayacağı ürün gereksinimine göre belirlenmelidir. Pure cache için çoğu durumda database commit'i cache hatasından daha önemli kabul edilir.

Dual-Write Problemi

İki ayrı sistem aynı transaction içinde güvenilir biçimde güncellenmediğinde arada tutarsızlık penceresi oluşur. Network failure yalnızca bir yazımın tamamlanmasına neden olabilir. Retry duplicate veya out-of-order update yaratabilir. Event-driven invalidation veya CDC bazı senaryolarda direct dual write'a göre daha güvenli olabilir. TTL son güvenlik ağı olarak stale kaydı sonsuza kadar yaşamaktan korur.

Write-Behind Caching Nedir?

Write-behind modelinde uygulama önce cache veya hızlı ara katmana yazar, authoritative database güncellemesi asenkron olarak sonradan gerçekleşir. Bu yaklaşım yüksek write throughput sağlayabilir. Buna karşılık cache artık geçici read optimization'dan daha kritik bir veri rolü üstlenir. Queue durability, ordering, retry ve idempotency temel gereksinimler haline gelir. Data loss kabul edilemiyorsa basit Redis cache yapılandırmasıyla write-behind tasarlamak yeterli değildir.

Önce Cache'e Yazma

Client request cache write tamamlandığında hızlı yanıt alabilir. Database henüz güncellenmemiştir. Redis kaybolursa pending write'ların nasıl kurtarılacağı açık olmalıdır. Persistence veya durable stream gibi ek mekanizmalar değerlendirilebilir. Bu pattern veri güvenilirliği gereksinimi düşük veya kontrollü eventual consistency isteyen workload'larda daha uygundur.

Asenkron Database Write

Background worker cache veya queue içindeki mutation'ları database'e uygular. Retry policy transient database hatalarını yönetir. Event ordering aynı entity için korunmalıdır. Worker idempotent olmalıdır çünkü aynı event yeniden işlenebilir. Monitoring queue lag ve oldest pending write yaşını izlemelidir.

Write Throughput

Database write request path'inden çıkarıldığı için kullanıcı latency'si düşebilir. Batch database write daha yüksek throughput sağlayabilir. Peak trafik queue içinde emilebilir. Ancak backlog sınırsız büyümemelidir. Database uzun süre yavaşsa load shedding veya backpressure uygulanmalıdır.

Data Loss Riski

Cache durable değilse process veya node kaybında henüz database'e gitmemiş değişiklikler kaybolabilir. Replication tek başına bütün failure senaryolarında kesin durability anlamına gelmez. Persistence ayarları ve failover semantics incelenmelidir. Finansal veya kritik state için daha güçlü durable messaging altyapısı gerekebilir. Write-behind seçimi performans değil veri kaybı toleransı kararıdır.

Kullanım Senaryoları

Analytics counter, telemetry aggregation veya gecikmeli olarak database'e yazılabilen düşük riskli state uygun aday olabilir. Shopping cart gibi kullanıcı state'inde durability expectation ayrıca değerlendirilmelidir. Cache ile durable queue rollerini birbirine karıştırmamak gerekir. Eventual consistency kullanıcı deneyiminde anlaşılır olmalıdır. Write-behind sistemi failure recovery testlerinden geçirilmeden production'a alınmamalıdır.

Write-Around Caching Nedir?

Write-around modelinde write işlemleri doğrudan authoritative storage'a gider ve cache'e yazılmaz. Sonraki ilk read cache miss yaşar ve değeri origin'den getirir. Bu yöntem yazılan fakat uzun süre okunmayacak veriyi cache'e gereksiz doldurmayı engeller. Read-after-write ilk erişimde daha yavaştır. Write-heavy ve düşük tekrar oranlı workload'larda memory verimliliği sağlayabilir.

Write'ların Cache'i Bypass Etmesi

Mutation cache population yapmadan database'e yazılır. Eğer eski cache value mevcutsa silinmesi gerekebilir. Aksi halde stale data sunulabilir. Write işlemi cache'e yeni payload serialization maliyeti getirmez. Cache yalnızca gerçek read talebi oluştuğunda veri saklar.

İlk Read'in Miss Olması

Yeni veya güncellenmiş kaydın sonraki ilk okuması origin'e gider. Bu miss beklenen behavior'dır. Read sonrası cache population gerçekleşir. Eğer veri hiç okunmazsa Redis memory'si kullanılmamış olur. Yüksek write ve düşük read tekrarında bu özellik avantaj sağlar.

Write-Heavy Workload'lar

Log metadata veya nadiren yeniden okunan kayıtlar write-around için aday olabilir. Cache'i her write'ta güncellemek memory churn yaratabilir. Read pattern gerçekten düşükse cache admission zaten sınırlı olmalıdır. Sık read-after-write yapan uygulamada ise kullanıcı latency'si artabilir. Workload ölçümü doğru pattern seçiminde belirleyicidir.

Hangi Redis Caching Pattern'i Seçilmeli?

Tek bir cache pattern bütün veri sınıfları için doğru değildir. Read-heavy catalog cache-aside kullanırken bazı configuration verileri write-through yaklaşımından faydalanabilir. Eventual consistency kabul edilen aggregation write-behind ile yönetilebilir. Strong freshness isteyen state doğrudan authoritative storage ve explicit invalidation gerektirebilir. Karar veriyi ne kadar sık okuduğunuz, ne kadar sık yazdığınız ve stale kalmasına ne kadar izin verdiğiniz üzerinden verilmelidir.

Read-Heavy

Read-heavy workload için cache-aside çoğu zaman sade başlangıçtır. İlk miss origin'e gider, sonraki yoğun trafik Redis'ten karşılanır. TTL ve invalidation freshness'i sınırlar. Stampede protection popüler key'lerde zorunlu hale gelir. Hit rate yüksekse database read QPS ciddi biçimde düşer.

Write-Heavy

Write-heavy sistemde cache'i her mutation'da güncellemek pahalı olabilir. Write-around gereksiz cache population'ı azaltabilir. Eğer yazılar asenkron database'e aktarılabiliyorsa write-behind ayrı seçenek olabilir. Veri kaybı toleransı burada kritik karardır. Cache'in write throughput kazancı consistency riskini karşılamıyorsa tercih edilmemelidir.

Strong Freshness

Güncel veri zorunluysa TTL tek başına yeterli olmayabilir. Database commit sonrası cache delete veya version-aware update kullanılabilir. Security permission gibi verilerde kısa TTL ek güvenlik katmanı sağlar. Race condition testleri concurrent mutation altında yapılmalıdır. Bazı state'ler için cache kullanmamak en güvenli seçim olabilir.

Eventual Consistency

Birkaç saniyelik gecikme kabul ediliyorsa event-driven invalidation ve write-behind seçenekleri genişler. Cache TTL safety net olarak çalışabilir. Consumer lag metriği freshness SLO'sunu temsil eder. User interface gecikmeli güncellemeyi doğal biçimde yönetmelidir. Event loss durumunda periyodik reconciliation düşünülmelidir.

High Throughput

Yüksek throughput için yalnızca cache pattern değil connection reuse, pipelining ve key distribution da önemlidir. Redis Cluster horizontal capacity sağlayabilir. Hot key tek shard'ı limitliyorsa cluster node eklemek tek başına çözüm olmayabilir. Local cache ve request coalescing Redis'e giden request sayısını düşürebilir. Performans tasarımı cache hit kadar network ve concurrency davranışını da kapsamalıdır.

Karar Matrisi

Read-heavy ve orta freshness için cache-aside iyi başlangıçtır. Çok güçlü read-after-write gereksiniminde write-through değerlendirilebilir. Write-heavy ve düşük read reuse için write-around uygundur. Eventual consistency ve yüksek write throughput gereken özel durumda write-behind düşünülebilir. Bu kararlar tek uygulama genelinde değil veri sınıfı bazında verildiğinde daha dengeli bir sistem ortaya çıkar.

TTL Nedir?

TTL bir cache key'inin ne kadar süre geçerli kalacağını belirleyen yaşam süresidir. Süre bittiğinde Redis key'i expired olarak değerlendirir ve kayıt artık normal read için kullanılamaz. TTL stale data riskini sınırlayan basit ve güçlü bir güvenlik katmanıdır. Aynı zamanda eski ve artık kullanılmayan verilerin memory'den zaman içinde temizlenmesini sağlar. Ancak doğru invalidation yerine çok kısa TTL kullanmak origin QPS'i gereksiz yükseltebilir.

Time to Live

Time to Live key'in kalan yaşam süresini ifade eder. Redis expiration saniye veya milisaniye hassasiyetinde ayarlanabilir. Business cache wrapper absolute veya relative TTL kullanabilir. TTL metriği kullanıcıya gösterilmek zorunda değildir. Operasyon açısından key'in beklenenden uzun yaşayıp yaşamadığını kontrol etmek için yararlıdır.

Expiration

Expiration süresi dolan key'in cache açısından geçersiz hale gelmesidir. Redis expired key'leri erişim sırasında ve aktif expiration mekanizmalarıyla temizler. Aynı saniyede çok fazla key expire olduğunda origin tarafında yük artabilir. Bu nedenle TTL dağılımı önemlidir. Expired keys metriği normal trafik ritmiyle birlikte yorumlanmalıdır.

TTL Neden Gereklidir?

Explicit invalidation hiçbir zaman kusursuz olmayabilir. Event kaybı veya deploy hatası cache'te stale key bırakabilir. TTL belirli üst sınırdan sonra bu değerin otomatik kaybolmasını sağlar. Ayrıca kullanılmayan cache entry'lerinin sonsuza kadar memory tüketmesini engeller. TTL bu yüzden correctness safety net ve capacity management aracı olarak birlikte çalışır.

TTL Olmadan Cache Kullanmanın Riskleri

Bir key explicit delete kaçırırsa süresiz eski veri sunabilir. Memory zamanla artık kullanılmayan key'lerle dolabilir. Schema değişikliğinde eski serialized object'ler yeni code tarafından okunabilir. Versioned key bu riski azaltır ama TTL yine cleanup sağlar. Pure cache namespace'lerinde TTL olmaması açıkça gerekçelendirilmelidir.

Redis TTL Nasıl Seçilmelidir?

Redis TTL tek bir sabit sayı değildir. Veri ne kadar sık değişiyor, origin sorgusu ne kadar pahalı ve kullanıcı ne kadar staleness kabul ediyor soruları birlikte değerlendirilmelidir. Çok kısa TTL hit rate'i azaltıp database'i yorabilir. Çok uzun TTL stale data riskini büyütür. Veri sınıfı bazında TTL ve gerektiğinde soft/hard expiration modeli kullanmak daha dengeli sonuç verir.

Veri Değişim Sıklığı

Dakikada bir değişen veri için saatlerce TTL çoğu zaman uygun değildir. Günlük değişen reference data daha uzun süre cache'te tutulabilir. Update event güvenilir biçimde invalidation yapıyorsa TTL daha uzun safety window olabilir. Çok hızlı değişen data hiç cache'lenmeyebilir. Update frequency production telemetry ile ölçülerek varsayıma dayalı karar azaltılmalıdır.

Database Maliyeti

Origin query çok pahalıysa cache miss daha maliyetlidir. Bu durumda daha uzun TTL veya refresh-ahead düşünülebilir. Ucuz primary-key lookup için kısa TTL yeterli olabilir. Database saturation riski yüksekse miss concurrency ayrıca sınırlandırılmalıdır. TTL sadece freshness değil origin'in cache'siz yükü taşıma kapasitesiyle de ilişkilidir.

Trafik Yoğunluğu

Saniyede yüz bin kez okunan key'in expiration davranışı saniyede bir kez okunan key'den farklı ele alınmalıdır. Hot key'de birkaç milisaniyelik miss penceresi bile yüzlerce origin çağrısı yaratabilir. Soft TTL ve single-flight bu nedenle yararlıdır. Düşük traffic key'lerde daha basit expiration yeterli olabilir. Traffic distribution percentile bazında incelenmelidir.

Kabul Edilebilir Staleness

Product açıklaması 30 saniye eski kalabilirken inventory değeri birkaç saniye bile kritik olabilir. Business owner kabul edilebilir staleness sınırını açıkça tanımlamalıdır. Cache TTL bu sınırın içinde seçilir. Stale-if-error kullanılıyorsa normal freshness ile degraded-mode freshness ayrı değerler olur. Kullanıcıya yanlış karar verdirecek verilerde stale window daha muhafazakâr tutulmalıdır.

Business Risk

Cache'te eski fiyat göstermek yanlış satış deneyimi oluşturabilir. Eski navigation text ise çok daha düşük risk taşır. TTL kararı yalnızca teknik değil business impact kararıdır. Risk yüksekse explicit invalidation ve authoritative verification eklenebilir. Checkout gibi final transaction adımında cache'teki fiyat yeniden database veya pricing source üzerinden doğrulanabilir.

Tek TTL Yerine Veri Türüne Göre TTL

Catalog content, profile, configuration ve availability için farklı TTL sınıfları tanımlanabilir. Library her key'e rastgele değer vermek yerine named policy kullanabilir. Örneğin reference_long, profile_medium ve inventory_short gibi policy'ler merkezi tutulabilir. Bu yaklaşım code review sırasında kararların görünür olmasını sağlar. Policy değişiklikleri configuration üzerinden kontrollü şekilde yapılabilir.

Soft TTL ve Hard TTL Nedir?

Soft TTL değerin ideal freshness süresini, hard TTL ise artık kesinlikle kullanılmaması gereken üst sınırı temsil eder. Soft TTL geçtiğinde değer hâlâ kullanıcıya sunulabilir fakat background refresh başlatılır. Bu model popüler key expiration anındaki toplu miss problemini azaltır. Hard TTL sonunda ise cache value kullanılmaz ve origin sonucu beklenir. Veri sınıfı stale kullanımına izin vermiyorsa soft TTL modeli uygulanmamalıdır.

Fresh Data Window

Fresh window içinde cache value doğrudan güvenli kabul edilir. Request herhangi bir refresh tetiklemez. Bu pencere normal TTL davranışındaki hit kadar hızlıdır. Süre veri güncelleme sıklığına göre seçilir. Hot key'lerde refresh işinin gereksiz sık çalışmasını engellemek için yeterince uzun tutulmalıdır.

Stale-but-Usable Window

Soft TTL geçtikten sonra value stale fakat hâlâ geçici olarak kullanılabilir kabul edilir. Kullanıcı eski değeri hemen alırken background worker yenilemeyi başlatır. Aynı anda tek refresh çalışması için lock veya single-flight gerekir. Bu window business tarafından onaylanan staleness sınırını aşmamalıdır. Refresh başarısız olursa stale-if-error policy ayrıca devreye girebilir.

Hard Expiration

Hard TTL geçtiğinde cache değeri artık kullanıcıya sunulmaz. Origin fetch zorunlu hale gelir. Çok yüksek trafik altında hard expiry anı yine stampede riski yaratabilir. Soft refresh normal koşullarda key'i bu noktaya gelmeden yenilemelidir. Hard TTL sistemin unutulmuş stale veriyi sonsuza kadar sunmasını engelleyen son sınırdır.

Background Refresh

Background refresh kullanıcı request'inden ayrılarak cache'i yeniler. Worker origin'den yeni value alır ve timestamp metadata ile cache'e yazar. Duplicate worker'ların aynı key'i yenilemesi önlenmelidir. Refresh latency ve error rate ayrıca izlenmelidir. Background sistem çökerse hard TTL safety net olarak çalışmaya devam eder.

Stale-While-Revalidate Pattern

Stale-while-revalidate yaklaşımı soft TTL geçmiş cache value'yu kullanıcıya hemen sunarken arka planda yenileme yapar. Böylece hot key expiration kullanıcı latency'sine doğrudan yansımaz. Origin yalnızca kontrollü refresh isteği görür. Pattern public catalog veya configuration gibi kısa süre eski kalabilen veriler için güçlüdür. Kesin finansal veya authorization state için kullanmadan önce business risk dikkatle değerlendirilmelidir.

Eski Veriyi Geçici Sunmak

Value soft expiry sonrasında tamamen kaybolmak yerine kısa stale window içinde kullanılabilir. Kullanıcı origin query'nin tamamlanmasını beklemez. Response metadata gerekirse data freshness bilgisini taşıyabilir. Stale window sınırsız olmamalıdır. Hard limit geçildiğinde normal miss path'e dönülmelidir.

Arka Planda Cache Refresh

İlk stale hit yenileme görevini tetikleyebilir. Diğer request'ler mevcut stale value'yu kullanmaya devam eder. Request coalescing veya lock tek refresh'i garanti etmeye yardımcı olur. Worker yeni value'yu atomik biçimde yazar. Error durumunda stale value'nun ne kadar daha kullanılacağı policy ile belirlenir.

Kullanıcı Latency'sini Azaltmak

Normal cache miss kullanıcıyı database latency'sine maruz bırakır. Stale-while-revalidate bu beklemeyi birçok request için kaldırır. Özellikle origin query yüzlerce milisaniye sürüyorsa fark büyüktür. Tail latency daha stabil hale gelir. Bunun karşılığında kontrollü staleness kabul edilir.

Hangi Veriler İçin Uygundur?

Product description, public profile ve reference content gibi veriler iyi aday olabilir. Çok sık değişen inventory veya security permission daha risklidir. Verinin eski kalması kullanıcıya yanlış işlem yaptırmamalıdır. Freshness window business owner ile belirlenmelidir. Gerçek kullanımda stale hit oranı ayrıca ölçülmelidir.

Stale-if-Error Pattern

Stale-if-error origin kaynağı hata verdiğinde belirli süre geçmiş cache value'yu kullanmaya devam etme yaklaşımıdır. Amaç freshness yerine availability'yi geçici olarak önceliklendirmektir. Downstream servis outage sırasında kullanıcıya tamamen hata vermek yerine biraz eski data sunulabilir. Maksimum stale süresi açıkça sınırlandırılmalıdır. Her veri sınıfı degraded mode için uygun değildir.

Database Hatasında Eski Cache'i Sunmak

Normal TTL dolmuş olsa bile cache value fiziksel olarak kısa süre daha tutulabilir. Origin fetch hata verirse application eski value'yu kullanır. Kullanıcıya veri güncelliğinin sınırlı olduğu gerekli durumlarda bildirilebilir. Database recovery olduğunda refresh yeniden denenir. Bu davranış cache storage'da stale payload'ın hard delete edilmemesini gerektirebilir.

Maximum Stale Window

Stale-if-error süresi örneğin birkaç dakika veya saat olabilir. Değer business riskine göre seçilir. Süre dolduğunda application artık eski veriyi kullanmaz. Bu aşamada error veya daha sınırlı fallback response verilebilir. Maximum window observability dashboard'unda policy olarak görünür tutulmalıdır.

Availability vs Freshness

Pattern doğrudan availability ve freshness arasında trade-off yapar. Public catalog için eski bilgi hizmet kesintisinden daha kabul edilebilir olabilir. Account balance için durum tersidir. Bu karar teknik ekip tarafından tek başına verilmemelidir. Product ve risk sahipleri veri sınıflarını önceden kategorize etmelidir.

Degraded Mode

Stale response sunmak daha geniş degraded-mode stratejisinin parçasıdır. Bazı endpoint'ler read-only hale gelebilir. Origin'e giden retry sayısı düşürülür. UI geçici güncellik sınırlamasını gösterebilir. Incident sona erdiğinde cache normal refresh davranışına döner.

TTL Jitter Nedir?

TTL jitter temel expiration süresine küçük rastgele sapma ekleyerek key'lerin aynı anda expire olmasını engeller. Özellikle toplu populate edilen binlerce kayıt aynı sabit TTL alıyorsa bu yöntem önemlidir. Expiration'lar zamana yayıldığı için database üzerinde ani miss dalgası azalır. Jitter freshness sınırını ihlal edecek kadar büyük seçilmemelidir. Yüzde veya sabit zaman aralığı data türüne göre belirlenebilir.

Aynı TTL'lerin Riskleri

Deployment sırasında yüz bin key'e tam 300 saniye TTL verilirse yaklaşık aynı anda expire olabilirler. Sonraki trafik database'e toplu şekilde döner. Connection pool ve CPU kısa sürede saturation yaşayabilir. Redis sağlıklı olduğu halde sistem cache avalanche yaşayabilir. Sabit TTL bu yüzden yüksek trafikte yeterli expiration stratejisi değildir.

Random Expiration

Temel TTL üzerine kontrollü random süre eklenebilir veya çıkarılabilir. Örneğin 300 saniyelik değer 270 ile 330 saniye arasında dağıtılabilir. Distribution uniform olmak zorunda değildir. Business freshness üst limiti korunmalıdır. Jitter logic ortak cache library içinde standardize edilirse ekipler aynı davranışı kullanır.

Cache Avalanche Önleme

Jitter expiration event'lerini zamana dağıtır. Böylece origin bir anda bütün key'leri rebuild etmek yerine daha düzenli yük görür. Tek hot key stampede probleminde jitter tek başına yeterli değildir. Request coalescing veya stale refresh de gerekir. Avalanche çok-key, stampede ise çoğu zaman aynı-key yoğunluğu olarak ayrı izlenmelidir.

Jitter Aralığı Nasıl Belirlenir?

Aralık normal TTL ve traffic volume'a göre seçilir. Çok kısa TTL'de 60 saniyelik jitter freshness davranışını bozabilir. Uzun TTL'de yüzde 10 veya yüzde 20 sapma kabul edilebilir olabilir. Peak traffic zamanlarına expiration yığılmaması simülasyonla test edilebilir. Gerçek expired-key timeline metriği tuning için kullanılır.

Cache Stampede Nedir?

Cache stampede popüler bir key bulunamadığında çok sayıda concurrent request'in aynı origin verisini aynı anda yeniden üretmeye çalışmasıdır. Bu durum thundering herd olarak da anılır. Normalde Redis tarafından emilen binlerce istek bir anda database veya downstream service'e ulaşır. Origin kapasitesi aşılırsa cache miss küçük bir olaydan geniş sistem arızasına dönüşebilir. Redis cache stampede TTL eviction ve distributed locking nasıl yönetilir sorusunda en kritik amaç aynı key için origin concurrency'yi sınırlamaktır.

Thundering Herd

Çok sayıda worker aynı olaya eşzamanlı tepki verdiğinde thundering herd oluşur. Cache expiration bu olaylardan biridir. Her worker key'in olmadığını görür ve database'e gider. Origin aynı hesaplamayı tekrar tekrar yapar. Single-flight veya distributed coordination bu çoğalmayı engeller.

Popüler Key Expiration

Ana sayfa veya popüler ürün key'i saniyede binlerce hit alabilir. TTL tam trafik anında biterse hemen binlerce miss oluşabilir. Soft TTL key'i kullanıcıya sunmaya devam ederek refresh'i kontrollü yapabilir. Refresh-ahead expiration gelmeden değer üretir. Hot key'lerde bu korumalar normal cache-aside'ın zorunlu uzantısıdır.

Eşzamanlı Cache Miss

İlk request ile cache populate edilene kadar geçen kısa pencerede diğer request'ler miss görür. Origin 200 milisaniye sürüyorsa yüksek QPS'te yüzlerce duplicate fetch oluşabilir. Instance-local coalescing aynı process içinde bunu önler. Multi-instance ortamda distributed lock veya stale response gerekir. Miss concurrency metriği problemi hit rate'ten daha net gösterebilir.

Database Overload

Database normalde cache sayesinde düşük read QPS ile çalışıyor olabilir. Stampede cache'in koruduğu yükü bir anda origin'e aktarır. CPU, I/O ve locks hızla artar. Slow query'ler daha da yavaşlayarak stampede süresini uzatır. Origin capacity yalnızca normal miss oranına göre değil failure ve cold-cache senaryosuna göre planlanmalıdır.

Connection Pool Exhaustion

Duplicate origin fetch application connection pool'un bütün slotlarını tüketebilir. Cache'lenemeyen kritik transaction'lar da bağlantı bulamaz. Böylece sadece cache endpoint'i değil bütün application etkilenir. Origin fetch concurrency semaphore ile ayrıca sınırlandırılabilir. Load shedding düşük öncelikli request'leri erken reddederek pool'u koruyabilir.

Cache Stampede Nasıl Önlenir?

Stampede için tek bir koruma yöntemi yerine birkaç katmanı birlikte kullanmak daha etkilidir. Request coalescing duplicate fetch sayısını düşürür. Distributed lock birden fazla application instance arasında koordinasyon sağlar. TTL jitter ve refresh-ahead expiration yoğunluğunu azaltır. Soft TTL veya probabilistic early expiration kullanıcı request'inin tam expiration anına denk gelme ihtimalini düşürür.

Request Coalescing

Aynı key için ilk request origin çağrısı başlatır. Sonraki request'ler yeni çağrı açmak yerine mevcut promise veya future sonucunu bekler. Sonuç geldiğinde bütün bekleyenlere paylaşılır. Bu yöntem process içinde çok ucuzdur. Distributed sistemde her instance yine bir fetch yapabileceği için gerekirse Redis lock ile tamamlanır.

Distributed Lock

Application instance'ları Redis üzerinde kısa ömürlü lock key edinmeye çalışabilir. Lock sahibi origin refresh yapar. Diğerleri stale value dönebilir veya kısa süre bekleyebilir. Lock TTL worker crash durumunda sonsuz kilidi önler. Lock release yalnızca lock sahibi tarafından güvenli token doğrulamasıyla yapılmalıdır.

TTL Jitter

Jitter çok sayıda farklı key'in aynı anda expire olmasını engeller. Tek hot key için duplicate miss'i doğrudan çözmez. Yine de cache avalanche ve toplu warming sonrası büyük yük dalgalarını azaltır. Shared library'de default jitter uygulanabilir. Critical freshness alanlarında aralık dikkatle sınırlandırılır.

Refresh-Ahead

Cache value TTL sonuna yaklaşmadan background job tarafından yenilenir. Hot key neredeyse hiç hard miss yaşamaz. Refresh frequency key popularity'ye göre dinamik olabilir. Origin error durumunda eski value korunabilir. Gereksiz bütün key'leri sürekli refresh etmek origin yükünü yükselteceği için sadece sıcak set hedeflenmelidir.

Soft TTL

Soft TTL geçtiğinde value hemen silinmez. Bir request refresh başlatırken diğerleri kısa süre eski value'yu kullanır. Kullanıcı latency'si sabit kalır. Hard TTL üst freshness sınırını korur. Veri stale sunulmaya uygun değilse bu yöntem tercih edilmemelidir.

Probabilistic Early Expiration

Key TTL sonuna yaklaştıkça bazı request'ler belirli olasılıkla erken refresh yapabilir. Böylece tek sabit expiration anında bütün request'ler miss olmaz. Refresh yükü zamana dağıtılır. Lock kullanılmadan stampede ihtimali azaltılabilir. Formula ve probability tuning gerçek request rate ile simüle edilmelidir.

Request Coalescing / Single-Flight Nedir?

Single-flight aynı cache key için aynı anda birden fazla origin request çalışmasını engelleyen concurrency pattern'idir. İlk istek çalışmayı başlatır. Diğerleri o işlemin sonucuna abone olur. Bu yöntem origin QPS'i büyük ölçüde azaltır. Ancak tek process registry'si birden fazla application instance arasındaki duplicate fetch'leri tek başına önleyemez.

Aynı Key İçin Tek Origin Request

Application key'i in-flight registry içinde arar. Entry yoksa fetch başlatır ve promise'i registry'ye ekler. Entry varsa yeni fetch açılmaz. Sonuç bütün request'lere döndürülür. İşlem tamamlandığında registry entry güvenli biçimde temizlenir.

In-Flight Request Registry

Registry process memory'sinde key ile promise eşlemesi tutabilir. Timeout ve error durumunda entry temizlenmelidir. Memory leak olmaması için abandoned promise'ler izlenir. Registry value cache değildir ve yalnızca devam eden işlemi temsil eder. Aynı key için concurrency burst'lerini emen geçici koordinasyon tabakasıdır.

Bekleyen Request'lerin Sonucu Paylaşması

Origin sonucu geldiğinde tüm bekleyen request'ler aynı value'yu alır. Cache populate işlemi bir kez yapılır. Error oluşursa hepsi aynı hata sonucunu görebilir. Retry'nin her waiter tarafından bağımsız yapılması yeni herd oluşturacağı için kontrollü olmalıdır. Error sonrası kısa negative/backoff cache bazı senaryolarda faydalıdır.

Tek Instance vs Distributed Sistem

Single-flight registry yalnızca aynı process içindeki request'leri görür. On application instance varsa teorik olarak aynı key için on origin fetch oluşabilir. Bu çoğu sistemde yine büyük iyileşmedir. Çok sıcak key'de distributed lock veya L2 stale policy eklenebilir. En ucuz koordinasyon katmanından başlayıp ölçülen ihtiyaca göre genişletmek daha doğrudur.

Redis Distributed Lock ile Cache Rebuild

Redis lock cache rebuild sırasında yalnızca tek worker'ın origin'e gitmesini sağlamak için kullanılabilir. Modern kullanımda SET key token NX PX duration benzeri atomic acquire yaklaşımı tercih edilir. Lock value benzersiz owner token taşımalıdır. İşlem bittikten sonra yalnızca kendi token'ını gören owner lock'ı kaldırmalıdır. Dağıtık lock correctness sınırları nedeniyle cache rebuild gibi toleranslı kullanım alanları, kritik iş transaction'larına göre daha uygun adaydır.

SET NX

SET komutunun NX koşulu key yalnızca mevcut değilse yazılmasını sağlar. Aynı command içinde expiration tanımlanması lock crash recovery için önemlidir. Ayrı SETNX ardından EXPIRE yapmak iki adım arasında failure penceresi oluşturabilir. Value olarak random veya unique token kullanılır. Acquire sonucu başarılı değilse worker lock sahibi değildir.

Lock Key

Lock key cache key ile ilişkili deterministic namespace kullanmalıdır. Örneğin lock:cache:product:123 gibi yapı anlaşılır olabilir. Tenant scope gerekiyorsa key'e dahil edilir. Lock key ile cache data key aynı olmamalıdır. Çok uzun key isimleri dev ölçekte memory overhead oluşturabileceği için standard kısa fakat açıklayıcı tutulabilir.

Lock TTL

TTL worker crash olduğunda lock'ın sonsuza kadar kalmasını engeller. Çok kısa TTL fetch tamamlanmadan lock'ın expire olmasına ve ikinci worker'ın başlamasına yol açabilir. Çok uzun TTL crash sonrası refresh'i gereksiz geciktirir. Timeout origin p99 süresinin üzerinde güvenlik payıyla seçilebilir. Uzun operation için lock extension düşünülse bile owner token kontrolü korunmalıdır.

Double-Checked Cache Read

Worker lock'ı aldıktan sonra cache'i yeniden kontrol etmelidir. Lock beklenirken başka worker değeri zaten populate etmiş olabilir. İkinci read gereksiz origin query'yi engeller. Value varsa lock sahibi fetch yapmadan çıkar. Bu basit adım distributed cache rebuild akışında ciddi gereksiz work azaltabilir.

Tek Worker'ın Database'e Gitmesi

Lock sahibi cache'i yeniden kontrol ettikten sonra origin fetch yapar. Diğer worker'lar stale value sunabilir veya kontrollü kısa bekleme uygulayabilir. Fetch başarılıysa cache TTL ile güncellenir. Origin error durumunda lock yine serbest bırakılmalıdır. Database'e giden concurrency'nin gerçekten düştüğü metric üzerinden doğrulanmalıdır.

Lock Release

Lock release basit DEL ile yapılmamalıdır, çünkü lock expire olup başka owner tarafından yeniden alınmış olabilir. Release sırasında stored token ile caller token karşılaştırılmalıdır. Eşleşme varsa key silinir. Bu işlem atomic script veya uygun conditional command ile yapılabilir. Owner identity kontrolü yeni lock'ın yanlışlıkla silinmesini engeller.

Distributed Lock Kullanmanın Riskleri

Distributed lock uygulandığında sistem otomatik olarak güçlü consistency kazanmaz. Network delay, process pause ve failover gibi olaylar lock geçerlilik süresini etkiler. Lock owner işi bitirmeden TTL dolabilir. Eski owner daha sonra geri dönüp stale write yapabilir. Bu nedenle kritik dış kaynak mutation'larında fencing token veya idempotency gibi ek mekanizmalar gerekir.

Lock Owner Crash

Worker lock aldıktan hemen sonra crash olabilir. TTL bulunmazsa diğer worker'lar sonsuza kadar bekleyebilir. Expiration bu riski azaltır. Ancak crash sırasında origin üzerinde yarım işlem kaldıysa bunun recovery'si lock tarafından çözülmez. Cache rebuild idempotent olduğu için bu senaryo business transaction'a göre daha yönetilebilirdir.

Çok Kısa TTL

Origin fetch bazen normalden uzun sürebilir. Lock TTL daha erken biterse ikinci worker yeni lock alır. Aynı anda iki rebuild çalışmaya başlar. Cache correctness çoğu durumda bozulmasa da origin yükü artar. TTL gerçek p99 ve failure latency'sine göre seçilmelidir.

Çok Uzun TTL

Worker crash olduğunda yeni refresh uzun süre başlamaz. Hot key hard expire olmuşsa bütün request'ler stale veya error görebilir. Uzun lock user impact'i büyütür. Lock extension mekanizması doğru owner doğrulamasıyla kullanılabilir. Basit cache refresh'te makul üst limit çoğu zaman daha güvenlidir.

Stale Lock

Network partition owner'ın lock state'ini yanlış değerlendirmesine neden olabilir. TTL sonunda başka worker lock alabilir. Eski worker hâlâ iş yapmaya devam edebilir. Cache write version metadata ile korunabilir. Critical resource update için daha güçlü concurrency control gereklidir.

Fencing Token

Fencing token her lock acquisition için monoton artan sequence sağlayarak downstream kaynağın eski owner işlemlerini reddetmesine yardım eder. Redis'teki basit random owner token release güvenliği sağlar fakat ordering garantisi vermez. Cache rebuild çoğu zaman fencing gerektirmez. Critical distributed write workflow'da gereksinim daha yüksektir. Downstream sistem token'ı anlayıp stale operation'ı reddedebilmelidir.

Lock'ın Idempotency Yerine Geçmemesi

Lock duplicate execution ihtimalini azaltır fakat tamamen ortadan kaldırmayabilir. Retry veya TTL expiry aynı operation'ın iki kez çalışmasına neden olabilir. Business write idempotent tasarlanmalıdır. Unique operation ID veya database constraint yardımcı olabilir. Lock yalnızca concurrency coordination katmanı olarak görülmelidir.

Probabilistic Early Expiration Nedir?

Probabilistic early expiration cache key hard expire olmadan önce bazı request'lerin yenileme başlatmasına izin verir. Olasılık TTL sonuna yaklaştıkça artırılabilir. Böylece bütün traffic aynı expiration anında miss yaşamaz. Hot key doğal request trafiği kullanılarak yenilenebilir. Model lock-free veya düşük lock kullanımlı stampede prevention yaklaşımı olarak değerlendirilebilir.

Expire Olmadan Refresh

Key hâlâ valid iken refresh kararı verilebilir. Kullanıcı eski fakat fresh kabul edilen value'yu alır. Background fetch yeni TTL ile value'yu yazar. Refresh başarısız olsa bile mevcut key hard expiry'ye kadar kullanılabilir. Bu behavior latency riskini azaltır.

Hot Key'lerde Erken Yenileme

Hot key çok sayıda request aldığı için erken refresh fırsatı fazladır. Cold key için gereksiz proactive work yapılmaz. Popularity doğal olarak refresh probability ile birleşir. Çok fazla request aynı anda refresh kararı verebilir, bu yüzden probability dikkatli ayarlanmalıdır. Gerekirse local single-flight ile tamamlanabilir.

Lock-Free Stampede Prevention

Probability yeterince düşük tutulduğunda tek veya az sayıda request refresh başlatır. Central distributed lock ihtiyacı azalır. Network failure lock state yönetimi ortadan kalkar. Yine de kesin tek refresh garantisi yoktur. Origin duplicate fetch'i tolere edebiliyorsa bu trade-off kabul edilebilir olabilir.

Refresh Olasılığının TTL Sonuna Doğru Artması

Key yeni yazıldığında refresh ihtimali çok düşük tutulabilir. Remaining TTL azaldıkça olasılık yükselir. Böylece refresh doğal olarak expiration öncesine yaklaşır. Formula traffic distribution ve origin cost'a göre ayarlanmalıdır. Simulation gerçek QPS ile yapılırsa aşırı refresh veya geç refresh riski daha iyi görülür.

Cache Avalanche Nedir?

Cache avalanche çok sayıda farklı key'in kısa zaman aralığında cache'ten kaybolması ve origin'e büyük miss trafiği göndermesidir. Ortak TTL kullanımı bu duruma neden olabilir. Redis restart veya yeni cache namespace deployment'ı da aynı etkiyi yaratabilir. Database normalden kat kat fazla read isteği görür. Yeterli koruma yoksa origin failure diğer servisleri de etkileyen cascade failure'a dönüşebilir.

Çok Sayıda Key'in Aynı Anda Expire Olması

Batch job binlerce key'i aynı anda yazıp aynı TTL verirse expiration zamanları birleşir. Birkaç dakika sonra binlerce farklı origin query aynı anda çalışmaya başlayabilir. TTL jitter bu dağılımı zamana yayar. Refresh-ahead en popüler key'leri expiration öncesi günceller. Expiration histogram monitoring bu pattern'i production'da görünür hale getirir.

Redis Restart Sonrası Cold Cache

Pure cache persistence olmadan restart ettiğinde bütün dataset kaybolabilir. Application tekrar traffic almaya başlayınca her key miss olur. Database doğrudan tam read yükünü görür. Cache warming ve traffic ramp-up bu riski azaltır. Persistence kullanımı restart süresini ve cold-start riskini farklı biçimde etkileyebilir.

Database Üzerindeki Ani Yük

Normalde yüzde 95 offload alan database cache kaybıyla bir anda yirmi kat read QPS görebilir. Connection pool ve CPU hızla dolar. Query latency arttıkça open request sayısı daha da yükselir. Rate limit ve origin concurrency control korunma sağlar. Cache fallback planı database'i cache'in yokluğunda kesinlikle sınırsız trafiğe açmamalıdır.

Cascade Failure

Database yavaşladığında application thread ve connection'ları beklemeye başlar. Upstream client retry yapar ve trafik daha da artar. Downstream servisler timeout yaşamaya başlayabilir. Circuit breaker ve load shedding bu zinciri kesmek için kullanılır. Cache outage testinin amacı yalnızca Redis'in geri gelmesini değil tüm sistemin ayakta kalmasını doğrulamaktır.

Cache Avalanche Nasıl Önlenir?

Avalanche prevention expiration zamanlarını dağıtmak ve origin'e dönen yükü kontrollü tutmak üzerine kuruludur. TTL jitter birinci savunmadır. Popüler key'ler staged cache warming ile önceden yüklenebilir. Refresh-ahead sürekli sıcak verileri canlı tutar. Rate limiting, load shedding ve circuit breaker cache'in tamamen kaybolduğu senaryoda origin'i koruyan son katmanlardır.

TTL Jitter

Jitter key'lerin aynı saniyede expire olmasını engeller. Özellikle batch population sonrası çok etkilidir. Aralık freshness limitine göre belirlenir. Namespace bazında farklı jitter uygulanabilir. Expired keys grafiğinin daha düz hale gelmesi başarının pratik göstergesidir.

Cache Warming

En popüler key'ler traffic açılmadan önce Redis'e yüklenebilir. Bütün dataset'i preload etmek gereksiz origin yükü ve memory tüketimi yaratır. Query logs hot set'i belirlemek için kullanılabilir. Warming job origin'i kontrollü QPS ile okur. Deploy version namespace değişiminde staged warming özellikle değerlidir.

Refresh-Ahead

High-hit key'ler TTL sonuna yaklaşırken background worker tarafından yenilenir. Böylece request path üzerinde miss oluşmaz. Refresh frequency hotness'e göre ayarlanabilir. Cold key'leri sürekli refresh etmekten kaçınılmalıdır. Worker failure hard TTL ve normal miss path ile güvenli fallback sağlar.

Rate Limiting

Cache kaybında origin'e gönderilecek toplam QPS sınırlandırılabilir. Düşük öncelikli request'ler daha erken reddedilebilir. Critical transaction'lar kapasite almaya devam eder. Retry-After gibi client davranışları kullanılabilir. Rate limit cache normal olduğunda gevşek, degraded mode'da daha korumacı olabilir.

Load Shedding

Sistem kapasite sınırına yaklaşınca bazı işleri hiç başlatmamak daha güvenlidir. Queue büyümeden düşük öncelikli response fallback ile döndürülebilir. Bu yaklaşım latency collapse'ı önler. Business priority endpoint'lere göre belirlenmelidir. Load shedding yalnızca Redis error'ına değil database saturation metric'lerine de bağlanabilir.

Circuit Breaker

Redis veya origin sürekli timeout veriyorsa tekrar denemek sistemi daha fazla zorlar. Circuit belirli hata eşiğinde open olur. Bir süre yeni call yapılmaz. Half-open aşamasında sınırlı probe recovery'yi test eder. Cache ve database circuit'leri ayrı dependency olarak yönetilebilir.

Cache Penetration Nedir?

Cache penetration cache'te ve origin'de bulunmayan kaynaklara sürekli istek gelmesi durumudur. Her request Redis miss yaşar ve ardından database miss üretir. Rastgele ID tarayan bot veya kötü input bu pattern'i büyütebilir. Cache hiçbir yük azaltamaz çünkü hiçbir key pozitif value olarak saklanmaz. Negative caching, validation ve Bloom filter gibi yöntemler origin'i korumaya yardımcı olur.

Olmayan Key'lere Sürekli Request

Client geçersiz product ID'leri arka arkaya deneyebilir. Her key benzersizse normal positive cache oluşmaz. Database sürekli primary-key miss yapmak zorunda kalır. Tek sorgu ucuz olsa bile milyonlarca request pahalı hale gelir. Input range ve format validation mümkünse Redis'e bile gitmeden uygulanmalıdır.

Redis Miss

Olmayan resource için key cache'te bulunmaz. Application origin fetch başlatır. Attack random key kullandığında hit rate hızla düşer. Miss rate metriği abuse detection için sinyal olabilir. Negative entry kısa süre tutulursa aynı invalid ID tekrarında hit oluşur.

Database Miss

Database lookup sonucunda kayıt bulunmaz. Bu sonuç da aslında belirli süre cache'lenebilen bir bilgidir. “Not found” ile gerçek cache absence birbirinden ayrılmalıdır. Sentinel value veya structured negative object kullanılabilir. Negative TTL pozitif data TTL'inden genellikle daha kısa tutulur.

Bot ve Abuse Senaryoları

Attacker milyonlarca random resource ID üretebilir. Cache'i bypass ederek database'e read amplification yaratır. Rate limit ve authentication ilk savunmadır. Bloom filter valid ID set'ine ait olmayan isteklerin önemli bölümünü erken eleyebilir. Security sistemi cache optimization'dan bağımsız olarak abuse davranışını kaydetmelidir.

Cache Penetration Nasıl Önlenir?

Penetration prevention invalid request'i origin'e ulaşmadan durdurmayı hedefler. Negative caching aynı olmayan key'in tekrar sorgulanmasını engeller. Bloom filter büyük valid-key set için hızlı membership kontrolü sağlayabilir. Input validation hatalı biçimleri erken reddeder. Rate limiting saldırı veya hatalı client'ın toplam request hızını sınırlar.

Negative Caching

Origin “bulunamadı” döndürdüğünde cache'e kısa süreli sentinel value yazılır. Sonraki aynı key isteği database'e gitmez. Response normal 404 behavior'ını korur. Yeni resource kısa süre sonra oluşabilecekse TTL kısa seçilir. Negative cache hit ayrı metric olarak izlenmelidir.

Null Value Caching

Gerçek null ile cache miss ayrımı yapılmalıdır. Özel placeholder veya structured state kullanılabilir. Client library'nin nil return davranışı doğrudan yeterli olmayabilir. Serialization formatında found:false gibi explicit alan tercih edilebilir. Böylece uygulama Redis key yok ile cached-not-found durumunu ayırır.

Kısa TTL

Negative entry uzun süre tutulursa sonradan oluşturulan resource görünmez kalabilir. Bu yüzden negative TTL çoğu durumda pozitif cache'ten daha kısadır. Create event explicit invalidation yapabiliyorsa süre biraz daha uzun olabilir. Attack durumunda çok kısa TTL database'i tekrar zorlayabilir. Risk ve create frequency arasında denge kurulmalıdır.

Bloom Filter

Bloom filter ID'nin valid set içinde bulunma ihtimalini çok düşük memory ile kontrol eder. Kesin negatif sonuç origin çağrısını güvenle engelleyebilir. Pozitif sonuç kesin değildir ve database lookup yine gerekebilir. False positive oranı filter size ve hash parametrelerine bağlıdır. Delete ve dynamic membership gereksinimi veri yapısı seçiminde ayrıca düşünülmelidir.

Input Validation

UUID beklenen endpoint'e birkaç karakterlik rastgele string geliyorsa database'e kadar gitmeye gerek yoktur. Format ve sınır validation application edge'inde yapılabilir. Authorization olmayan resource enumeration ayrıca reddedilir. Validation business existence kontrolü değildir. Yine de gereksiz cache ve origin load'un önemli kısmını erken azaltabilir.

Rate Limiting

Aynı IP, user veya token çok fazla miss üretiyorsa hız sınırı uygulanabilir. Rate limit Redis üzerinde atomic counter veya script ile tutulabilir. Cache miss abuse için daha düşük threshold kullanılabilir. Distributed application instance'lar ortak limit state'ini paylaşabilir. Fail-open veya fail-closed davranışı endpoint riskine göre belirlenmelidir.

Negative Caching Nedir?

Negative caching bir kaynağın bulunamadığı sonucunu belirli süre saklamaktır. Amaç tekrar eden aynı geçersiz request'in origin'e ulaşmasını engellemektir. Cache entry gerçek value'dan ayrılabilir bir marker taşımalıdır. TTL genellikle kısa tutulur. Resource sonradan oluşturulduğunda create event negative key'i temizleyebilirse freshness daha iyi korunur.

“Bulunamadı” Sonucunu Cache'lemek

Database 404 semantiğine karşılık gelen sonuç döndürdüğünde Redis'e negative entry yazılabilir. Aynı request tekrarında doğrudan 404 dönülür. Database query sayısı azalır. Error veya timeout sonucu “bulunamadı” olarak cache'lenmemelidir. Yalnızca authoritative not-found sonucu negative cache'e uygundur.

Null Placeholder

Redis key absence ve cached null birbirinden ayrılmalıdır. Özel sentinel string kullanılabilir. Daha güvenli yaklaşım versioned structured payload saklamaktır. Application serializer bu state'i type-safe biçimde okuyabilir. User-controlled data sentinel ile çakışmamalıdır.

Negative TTL

Negative TTL kaynağın ne kadar sürede oluşabileceğine göre seçilir. Product ID immutable ve hiç oluşmayacaksa daha uzun süre düşünülebilir. Username availability gibi hızla değişen state kısa tutulmalıdır. Attack defense ile freshness arasında denge kurulur. Create operation explicit delete yapıyorsa stale negative window azalır.

Sonradan Oluşturulan Kaynak Problemi

Bir ID önce bulunamazken birkaç saniye sonra oluşturulabilir. Negative entry hâlâ aktifse kullanıcı yanlış 404 alır. Create transaction sonrası ilgili negative key silinebilir. Event-driven invalidation başka service'lerdeki cache'leri de temizleyebilir. TTL son güvenlik ağı olarak kalır.

Bloom Filter Redis Cache Önünde Nasıl Kullanılır?

Bloom filter çok büyük valid identifier set'inin membership kontrolünü az memory ile yaklaşık biçimde yapar. Request önce filter'a sorulur. Filter kesin “yok” diyorsa database ve cache lookup tamamen atlanabilir. “Var olabilir” cevabı ise kesin değildir ve normal akış devam eder. Bu yapı cache yerine geçmez, yalnızca olmayan resource trafiğini azaltan ön filtre görevi görür.

Membership Test

Identifier birkaç hash function ile bit positions'a dönüştürülür. Gerekli bitlerden biri yoksa element kesinlikle set içinde değildir. Bütün bitler varsa element bulunabilir. Lookup çok ucuzdur. Filter bütün resource payload'ını saklamadığı için memory efficiency yüksektir.

Kesin Olmayan Pozitif Sonuç

Bloom filter false positive üretebilir. Filter “olabilir” dediğinde record gerçekten olmayabilir. Bu durumda Redis ve database normal lookup yapar. Correctness bozulmaz, yalnızca origin tasarrufu o request için gerçekleşmez. False positive oranı capacity planning sırasında belirlenmelidir.

Olmayan ID'leri Erken Eleme

Random ID saldırısında çoğu identifier filter tarafından kesin negatif olarak reddedilir. Database hiç sorgulanmaz. Cache namespace de gereksiz negative key'lerle dolmaz. Filter refresh ve data onboarding süreci güvenilir olmalıdır. Yeni valid ID filter'a eklenmeden request reddedilirse false negative benzeri uygulama hatası oluşturulabilir.

False Positive

False positive Bloom filter tasarımının kabul edilen özelliğidir. Bit array doldukça oran yükselir. Expected item count ve error rate başlangıçta seçilmelidir. Capacity aşılırsa yeni filter generation gerekebilir. Metric gerçek positive ve false-positive lookup oranını örneklemeyle izleyebilir.

Bloom Filter'ın Cache Yerine Geçmemesi

Bloom filter value saklamaz. Product detail veya user profile geri döndüremez. Yalnızca membership hakkında yaklaşık bilgi verir. Redis cache yine gerçek serialized değeri veya negative marker'ı taşır. İki katmanın görevleri farklıdır.

Hot Key Problemi Nedir?

Hot key toplam Redis trafiğinin orantısız bölümünü tek bir key'in almasıdır. Cluster kullanılsa bile o key tek hash slot ve tek primary node üzerinde bulunur. Diğer shard'lar boş kapasiteye sahipken hot shard CPU veya network sınırına ulaşabilir. Ana sayfa configuration veya viral ürün örnek olabilir. Çözüm yalnızca cluster'a node eklemek değil aynı key üzerindeki talebi dağıtmaktır.

Trafiğin Tek Key'de Yoğunlaşması

Zipf benzeri access distribution'da birkaç key toplam request'in büyük kısmını alabilir. Global hit rate bunu gizler. Per-key sample veya top-key telemetry gerekir. Hot key read-only ise local replication seçenekleri geniştir. Write-hot key daha zor consistency sorunları oluşturur.

Tek Shard Bottleneck

Redis Cluster key'i tek slot üzerinden tek primary'ye yönlendirir. Hot key bu primary'nin CPU veya network kapasitesini doldurabilir. Yeni shard eklemek key'in tek kopya olma özelliğini değiştirmez. Key replication veya L1 cache kullanmak gerekir. Shard-level metrics imbalance'ı gösterir.

Cluster'ın Toplam Kapasitesinden Yararlanamama

Dört shard toplamda yüksek throughput sunabilir. Trafiğin yüzde 70'i tek key'e gidiyorsa bir shard erken saturation yaşar. Ortalama cluster CPU düşük görünebilir. Maximum shard CPU ve QPS ayrı izlenmelidir. Capacity planning average yerine hottest shard üzerinden yapılmalıdır.

Popüler Ürün ve Ana Sayfa Örnekleri

Viral ürün kampanya sırasında milyonlarca kez okunabilir. Ana sayfa feature configuration bütün request'lerde kullanılabilir. Bu veriler çok sık değişmiyorsa process-local cache etkili olur. Short L1 TTL Redis request'lerini ciddi biçimde azaltır. Invalidation gerektiğinde Redis client-side tracking veya event broadcast kullanılabilir.

Hot Key Nasıl Tespit Edilir?

Hot key tespiti request dağılımının key seviyesinde gözlemlenmesini gerektirir. Redis server ve application telemetry birlikte kullanılabilir. Shard CPU veya network dengesizliği ilk sinyaldir. Sampling bütün keyspace'i sürekli taramadan sıcak anahtarları bulmaya yardım eder. Kişisel veya hassas key bilgileri metric sistemine aktarılırken hashing veya redaction kullanılmalıdır.

Per-Key Request Frequency

Application cache wrapper key namespace ve anonymized hash bazında request count tutabilir. Top-N key listesi belirli aralıklarla çıkarılır. Exact identifier yerine güvenli fingerprint kullanılabilir. Frequency hit ve miss olarak ayrılır. Çok hot ve sık miss olan key özellikle yüksek risk taşır.

Shard CPU

Cluster node'larından biri sürekli diğerlerinden yüksek CPU kullanıyorsa hot shard olabilir. Slow command yoksa workload distribution incelenir. Tek key veya slot grubu yoğunluk yaratabilir. Resharding farklı normal keys'i dağıtabilir. Tek hot key aynı slot içinde kaldığı için başka çözüm gerekir.

Network Throughput

Büyük veya çok sık okunan key network output'u yükseltebilir. CPU düşük olsa bile network bandwidth sınırı görülebilir. Big-hot key birleşimi özellikle pahalıdır. Compression veya local cache değerlendirilebilir. Node başına bytes-out metriği QPS ile birlikte okunmalıdır.

Uneven QPS

Cluster node QPS değerleri birbirinden belirgin farklı olabilir. Slot distribution eşit olsa bile access distribution eşit değildir. Key count dengelemesi traffic dengelemesi anlamına gelmez. Hot slot başka node'a taşındığında yalnızca bottleneck yer değiştirebilir. L1 veya replicated read yaklaşımı daha kalıcı olabilir.

Sampling ve Telemetry

Her request için yüksek-cardinality metric üretmek monitoring sistemini zorlayabilir. Sampling veya top-key sketch kullanılabilir. Redis diagnostic araçları kısa dönem analiz için yardımcı olur. Application trace belirli endpoint'in hot key'i oluşturduğunu gösterir. Telemetry maliyeti production latency'sini etkilemeyecek şekilde tasarlanmalıdır.

Hot Key Nasıl Çözülür?

Hot key çözümünde amaç aynı değerin tek Redis execution path'ine ulaşan request sayısını azaltmaktır. Local L1 cache en etkili yöntemlerden biridir. Read-only veya düşük-change data farklı replicated key'lere bölünebilir. Request coalescing miss yükünü azaltır. Client-side caching Redis'in invalidation bilgisini kullanarak uygulama memory'sini daha güvenilir L1 katmanına dönüştürebilir.

Local L1 Cache

Application process hot value'yu kısa süre memory'de saklar. Her request Redis'e gitmez. Beş saniyelik L1 TTL bile binlerce Redis call azaltabilir. Birden fazla instance farklı kopya taşıdığı için staleness artar. Update-sensitive data'da invalidation event veya client tracking kullanılabilir.

Key Replication

Read-only hot value birkaç logical key kopyasına yazılabilir. Client key suffix'i random veya hash üzerinden seçer. Trafik farklı slots ve shard'lara dağılır. Invalidation bütün kopyaları güncellemek veya silmek zorundadır. Çok sık değişen data için write amplification yüksek olabilir.

Key Splitting

Aggregate counter gibi key tek value olmak zorunda değilse shard edilmiş counter'lara bölünebilir. Write'lar farklı key'lere dağıtılır. Read gerektiğinde alt değerler toplanır. Bu yaklaşım semantics'i değiştirir ve her veri için uygun değildir. Approximate veya eventually aggregated metrics için güçlü olabilir.

Request Coalescing

Hot key cache miss yaşadığında duplicate origin fetch'leri engeller. Normal hit trafiğini azaltmaz. L1 ile birlikte kullanıldığında hem Redis hem origin yükü düşebilir. Single-flight implementation küçük ve hızlı olmalıdır. Failure sonrası waiter'ların aynı anda retry yapması önlenmelidir.

Client-Side Caching

Redis Tracking uygulama memory'sindeki cache entry'leri invalidation mesajlarıyla yönetmeye yardımcı olur. Client sık read'i local memory'den karşılayabilir. Redis key değiştiğinde ilgili local value silinir. Connection kaybında local cache flush edilmelidir. Bu model network request sayısını hot workload'da belirgin biçimde azaltabilir.

Dedicated Hot-Key Cache

Çok özel workload'da hot content ayrı Redis instance veya memory layer'a taşınabilir. Böylece diğer cache traffic'inden izolasyon sağlanır. Operasyon maliyeti arttığı için ilk tercih olmamalıdır. Content distribution veya application topology bu kararı haklı çıkarabilir. Dedicated katmanın failure ve invalidation süreci ayrıca yönetilmelidir.

Big Key Nedir?

Big key tek Redis key altında normal workload'a göre çok büyük amount veya collection taşıyan kayıttır. Büyük string birkaç megabayt olabilir. Hash, set veya sorted set milyonlarca element içerebilir. Big key problemi yalnızca memory miktarı değildir, bazı komutların ve deletion işlemlerinin uzun sürmesine neden olabilir. Hot key ile big key farklı kavramlardır, fakat aynı key hem büyük hem sıcak olduğunda etkileri birleşir.

Büyük String

Büyük serialized JSON veya binary blob tek string olarak saklanabilir. GET her seferinde bütün payload'ı network üzerinden taşır. Client deserialize CPU'su yükselir. Birkaç alan gerekiyorsa büyük object cache verimsiz olabilir. Daha küçük parçalar veya farklı data model değerlendirilebilir.

Çok Büyük Hash

Hash milyonlarca field içerdiğinde bazı operasyonlar yüksek cost oluşturabilir. Tek field erişimi yine verimli olabilir fakat full read ve delete dikkat gerektirir. Hash'in tek slot üzerinde bulunması cluster distribution'ını sınırlar. Büyük entity doğal segmentlere ayrılabilir. Key count artışı ile collection size arasında denge kurulur.

Çok Büyük Set

Set membership hızlı olabilir ancak bütün set üzerinde işlem yapan komutlar element sayısıyla büyür. Intersection veya union büyük collection'da latency yaratabilir. Tek command Redis processing path'ini uzun süre meşgul edebilir. Set parçalama veya precomputed result düşünülebilir. Command complexity production review'da kontrol edilmelidir.

Büyük Sorted Set

Sorted set leaderboard ve ranking için uygundur. Milyonlarca member normal olabilir fakat geniş range veya removal operasyonları pahalılaşabilir. Tek tenant'ın dev sorted set'i hot shard yaratabilir. Time bucket veya partitioned leaderboard tasarımı değerlendirilebilir. Query'ler küçük rank window'larıyla sınırlandırılmalıdır.

Hot Key ile Big Key Arasındaki Fark

Hot key erişim frekansıyla ilgilidir. Big key value veya collection boyutuyla ilgilidir. Küçük bir configuration key son derece hot olabilir. Nadiren okunan dev archive hash big fakat cold olabilir. Monitoring iki problemi ayrı metriklerle izlemelidir.

Big Key'ler Neden Redis Latency'sini Artırabilir?

Big key network, serialization ve command execution süresini artırabilir. Redis command processing sırasında uzun süren O(N) operation diğer request'lerin beklemesine yol açabilir. Delete veya expire bile büyük object üzerinde ek cleanup maliyeti oluşturabilir. Replication büyük mutation'ı replica'lara taşımak zorundadır. Big-key detection bu nedenle yalnızca memory capacity çalışması değildir.

Network Payload

On megabaytlık value her GET'te network üzerinden taşınır. Server processing hızlı olsa bile transmission latency büyür. Application instance network bandwidth'i de tüketilir. Local cache bazı tekrarları azaltabilir. Daha küçük projection payload tasarımı çoğu zaman daha iyi çözümdür.

Serialization

Büyük JSON serialize ve parse etmek uygulama CPU'sunu tüketir. Redis latency düşük görünürken endpoint yine yavaş olabilir. Binary format payload boyutunu azaltabilir. Schema evolution göz önünde bulundurulmalıdır. Cache metric yanında serialization timing ölçülmelidir.

Delete/Expire Cost

Büyük collection'ın silinmesi cleanup işi gerektirir. Redis bazı durumlarda asynchronous freeing için uygun komut veya configuration kullanabilir. Expire anında büyük object removal latency yaratabilir. Production latency monitoring bu spike'ları gösterebilir. Çok büyük object'i küçük bağımsız key'lere bölmek deletion cost'u dağıtabilir.

O(N) Operasyonlar

Collection üzerinde bütün elementleri dolaşan command boyut büyüdükçe daha uzun sürer. Command documentation complexity bilgisini kontrol etmek önemlidir. Development'ta küçük sample hızlı görünür. Production milyon elementte aynı command ciddi latency yaratabilir. SLOWLOG bu tür operation'ları bulmaya yardımcı olur.

Replication Trafiği

Büyük write veya delete replica stream üzerinde yüksek byte volume oluşturabilir. Replica apply gecikebilir. Cluster failover sırasında stale replication state riski artabilir. Network throughput ve lag birlikte izlenmelidir. Big-key mutation batch veya data model değişikliğiyle azaltılabilir.

Cache Key Tasarımı Nasıl Yapılmalıdır?

Cache key verinin identity'sini deterministic ve çakışmasız biçimde temsil etmelidir. Namespace application ve domain ownership'ini gösterir. Tenant, entity ve query parametreleri yalnızca sonucu gerçekten değiştiriyorsa key'e dahil edilir. Key sıralaması ve canonicalization aynı request'in farklı string'lerle iki cache kaydı üretmesini engeller. Hassas kullanıcı verisini doğrudan key içine yazmak log ve monitoring sistemleri açısından riskli olabilir.

Deterministic Keys

Aynı logical request her zaman aynı key'i üretmelidir. Query parametre sırası canonical hale getirilir. JSON object doğrudan stringify edilirse property order sorunları çıkabilir. Hash kullanılacaksa stable serialization uygulanır. Deterministic behavior cache hit ihtimalini yükseltir.

Namespace

Namespace farklı domain veya service key'lerini ayırır. Örneğin catalog: ve profile: gibi prefix'ler kullanılabilir. Operasyon sırasında belirli key grubunu anlamayı kolaylaştırır. Redis Cluster'da key hash tag kullanımı prefix'ten ayrı düşünülmelidir. Namespace version bilgisiyle birleştirilebilir.

Entity Type

Key hangi object türünü temsil ettiğini göstermelidir. Aynı numeric ID farklı entity'lerde çakışmamalıdır. user:123 ve product:123 bunun basit örneğidir. Generic cache:123 gibi key'ler debugging'i zorlaştırır. Domain standardı bütün service'lerde ortak olabilir.

Entity ID

Entity ID cache identity'nin temel parçasıdır. Public identifier çok uzun veya hassassa stable hash kullanılabilir. ID formatı değiştiğinde version migration planlanmalıdır. Tenant-scoped ID global unique değilse tenant bilgisi eklenmelidir. Key generation helper bu kuralları merkezi uygular.

Query Parameters

Response'u değiştiren filtre, sort veya page cursor key'e dahil edilmelidir. Gereksiz parametreler key cardinality'yi büyütür. Default value ile explicit default aynı key'e normalize edilebilir. User input length sınırlandırılmalıdır. Authorization sonucu değiştiren context query parameter olmasa bile cache identity'ye dahil edilmelidir.

Tenant ID

Multi-tenant cache'te aynı entity ID farklı tenant'larda bulunabilir. Tenant prefix data leak riskini azaltan temel izolasyon katmanıdır. Yine de authorization yalnızca key namespace'e bırakılmamalıdır. Hot tenant keyspace'i ayrı quota veya cluster'a taşınabilir. Tenant identifier loglarda hassas kabul ediliyorsa tokenize edilebilir.

Versioned Cache Keys Neden Kullanılır?

Versioned key cache schema veya serialization değişikliğinde eski object'lerle yeni uygulamanın karışmasını engeller. Deployment yeni version prefix'ini kullanmaya başlar. Eski key'ler TTL süresi sonunda doğal biçimde kaybolur. Global delete veya keyspace scan gereksinimi azalır. Bu model rolling deployment sırasında eski ve yeni application version'larının kendi cache formatlarıyla güvenli çalışmasına yardımcı olur.

user:v1:123

user:v1:123 version bilgisini key identity içinde taşır. Yeni payload schema için v2 oluşturulabilir. Eski code v1'i okumaya devam eder. New deployment v2 population yapar. Migration tamamlandığında v1 key'ler TTL ile temizlenir.

Cache Schema Değişikliği

Serialized object'e alan eklemek her zaman breaking değildir. Fakat field rename veya type değişimi eski cache value ile uyumsuz olabilir. Version bump bu riski ortadan kaldırır. Serializer failure yüzünden bütün request'lerin error vermesi engellenir. Schema version change deployment planının açık bir parçası olmalıdır.

Deployment Sonrası Eski Object'ler

Rolling deploy sırasında bazı instance'lar eski code ile çalışabilir. Tek key namespace kullanılırsa iki version birbirinin cache value'sunu overwrite edebilir. Versioned key izolasyon sağlar. Deployment tamamlandıktan sonra eski namespace expire olur. Memory geçici olarak iki katına çıkabileceği için capacity planlanmalıdır.

Global Cache Busting

Namespace version artırmak geniş cache invalidation için hızlı yöntemdir. Milyonlarca key'i DEL etmek gerekmez. Bunun karşılığında yeni namespace cold cache olarak başlar. Staged warming yapılmalıdır. Version bump sık kullanılırsa abandoned key memory'si TTL süresince büyüyebilir.

Eski Key'lerin TTL ile Kaybolması

Eski namespace active application tarafından artık okunmaz. TTL memory'yi zaman içinde otomatik geri kazanır. Key scan ve bulk delete production riskinden kaçınılır. Çok uzun TTL varsa migration memory footprint'i büyüyebilir. Versioned cache için de makul expiration policy korunmalıdır.

Cache Invalidation Nedir?

Cache invalidation source of truth değiştiğinde eski cache kaydının artık kullanılmamasını sağlayan süreçtir. TTL en basit invalidation biçimidir. Explicit delete mutation sonrasında key'i hemen kaldırabilir. Event-driven invalidation farklı service cache'lerine değişikliği yayabilir. Version-based yaklaşım geniş schema veya dataset değişikliklerinde eski namespace'i terk etmeyi sağlar.

Stale Cache

Database değişmiş ancak cache eski value'yu tutuyorsa stale cache oluşur. Staleness her zaman bug değildir, belirlenen freshness window içindeyse tasarımın parçası olabilir. Sorun izin verilen sınırın aşılmasıdır. Cache payload'a source version veya update timestamp eklemek debugging'i kolaylaştırabilir. Stale incident'lar invalidation gap'lerini bulmak için analiz edilmelidir.

TTL-Based Invalidation

Key belirli süre sonunda otomatik geçersiz olur. Implementation basittir. Değişiklik anında güncelleme garanti etmez. Düşük riskli content için yeterli olabilir. Critical data explicit veya event-driven invalidation ile tamamlanmalıdır.

Explicit Delete

Mutation başarılı olduktan sonra ilgili cache key silinir. Sonraki read database'den yeni state'i populate eder. Delete cache update'e göre concurrent ordering riskini bazı durumlarda azaltır. Delete başarısız olursa stale key TTL'e kadar kalabilir. Retry veya event safety net kullanılabilir.

Event-Driven Invalidation

Domain change event mesajlaşma sistemi üzerinden yayınlanır. Cache consumer ilgili key'leri siler veya günceller. Birden fazla service kendi cache'ini bağımsız yönetebilir. Event delivery gecikmesi eventual consistency window oluşturur. TTL kayıp event'e karşı son güvenlik ağıdır.

Version-Based Invalidation

Key namespace version değiştirilir. Eski değerler bir anda unreachable hale gelir. Large deployment veya schema change için kullanışlıdır. Cold cache riski yaratır. Warming ve traffic ramp-up ile birlikte uygulanmalıdır.

Database Güncellendiğinde Cache Nasıl Yönetilmeli?

Cache-aside sistemde güvenli temel yaklaşım önce authoritative database'i güncellemek, commit sonrası ilgili cache key'i silmektir. Böylece database başarısız olduğunda cache yanlış yeni state taşımaz. Delete ile yeni value update arasında farklı concurrency riskleri vardır. Source of truth açık kaldığı sürece cache yeniden üretilebilir. Mutation ve invalidation arasındaki küçük pencere TTL ve event retry ile sınırlandırılabilir.

Önce Database

Business transaction önce authoritative storage'da commit edilmelidir. Cache'i önce değiştirmek database failure durumunda false state oluşturur. Database commit başarılı olduktan sonra invalidation yapılır. Transaction outbox gibi pattern event publish güvenilirliğini artırabilir. Cache hiçbir zaman başarısız database write'ı başarılıymış gibi göstermemelidir.

Sonra Cache Delete

Commit sonrasında ilgili key silinir. Sonraki read güncel database value'yu getirir. Delete operation idempotent olduğu için retry kolaydır. Aynı key zaten yoksa sorun oluşmaz. Delete başarısızlığı monitoring ve retry mekanizmasına girmelidir.

Cache Update

Delete yerine cache doğrudan yeni value ile güncellenebilir. Bu ilk sonraki read'in miss yaşamasını önler. Ancak concurrent writer ordering stale value'nun son yazılmasına neden olabilir. Version veya database commit sequence bu riski azaltabilir. Simple systems delete-on-mutation ile daha az concurrency riski taşır.

Race Condition

Read eski database value'yu alırken başka thread mutation yapabilir. Mutation cache'i siler, ardından eski read sonucunu cache'e tekrar yazabilir. Bu klasik cache-aside race condition'dır. Short TTL riski sınırlar. Version check, delayed double delete veya transaction-aware population gibi yöntemler kritik data için değerlendirilebilir.

Source of Truth

Hangi sistemin authoritative olduğu tartışmasız olmalıdır. Pure cache modelinde database gerçek state'i taşır. Redis value kaybolduğunda yeniden üretilebilir. Write-behind modelinde bu varsayım değişir ve durability tasarımı daha karmaşık hale gelir. Operations ekibi her namespace'in state classification bilgisini bilmelidir.

Cache'i Update Etmek mi Delete Etmek mi?

Cache mutation sonrasında update etmek miss'i azaltır, delete etmek ise concurrency modelini sadeleştirir. Çoğu cache-aside sistemde delete-on-mutation güçlü bir varsayılandır. Sonraki read authoritative source'tan yeni value üretir. Çok yüksek read-after-write trafiğinde write-through update daha iyi olabilir. Karar stale overwrite riski, origin cost ve freshness ihtiyacına göre verilmelidir.

Concurrent Write Problemi

İki writer farklı sırada database ve cache update yapabilir. Database son state B iken cache geciken writer nedeniyle A olabilir. Version-aware write bu durumu engelleyebilir. Delete operation stale value yazmak yerine key'i kaldırdığı için daha basit davranır. High concurrency entity'lerde update strategy özel test gerektirir.

Delete-on-Mutation

Database commit sonrası cache key silinir. Bir sonraki read miss yaşar. Origin'den fresh value getirilir. Delete idempotent olduğu için retry kolaydır. Cache hit performansı kısa bir miss pahasına consistency riskini azaltır.

Sonraki Read'de Yeniden Populate

İlk read database'e gider ve value'yu cache'e yazar. Hot key ise aynı anda duplicate read oluşabilir. Single-flight bu populate işlemini birleştirir. Sonraki request'ler normal hit yaşar. Mutation az, read çok olan sistemde bu model verimlidir.

Write-Through Gerektiren Senaryolar

Mutation sonrası hemen yoğun read gelecekse cache update miss yükünü azaltabilir. User-facing profile save sonrası aynı ekranın yeniden okunması örnektir. Cache write başarısızsa database state yine doğru kalmalıdır. Versioning stale overwrite riskini sınırlar. Strong cache freshness requirement varsa dual-write failure handling ayrıntılı tasarlanmalıdır.

Event-Driven Cache Invalidation

Event-driven invalidation değişiklik bilgisini publisher'dan cache sahiplerine mesajlaşma üzerinden taşır. Bu yaklaşım microservice'lerde cache ownership'i dağıtmayı kolaylaştırır. Domain event ilgili entity ve version bilgisini içerir. Consumer kendi Redis namespace'ini günceller veya siler. Event gecikmesi ve kaybı nedeniyle TTL yine güvenlik ağı olarak tutulmalıdır.

Domain Event

Event “ProductUpdated” gibi business değişikliğini ifade eder. Cache-specific “delete key X” mesajından daha gevşek coupling sağlayabilir. Consumer kendi key modelini bilir. Event schema versionlanmalıdır. Sensitive payload yerine minimum entity ID ve change metadata taşınabilir.

Kafka/RabbitMQ

Mesajlaşma altyapısı event'i bir veya birden fazla consumer'a iletir. Delivery semantics kullanılan sisteme göre farklıdır. Consumer duplicate event'i tolere etmelidir. Ordering aynı entity için önemli olabilir. Cache invalidation idempotent delete kullandığında duplicate delivery genellikle sorun yaratmaz.

Cache Consumer

Consumer event'i okuyup ilgili Redis key'lerini bulur. Key naming deterministic ise lookup basittir. Query-result cache gibi bir entity'nin hangi key'leri etkilediğini bulmak daha zor olabilir. Tag veya version strategy kullanılabilir. Consumer lag freshness SLO'suyla ilişkilendirilmelidir.

Near-Real-Time Invalidation

Event birkaç yüz milisaniye içinde işlendiğinde cache çoğu kullanıcı için hızla güncellenir. Bu yine tam synchronous consistency değildir. Mesaj broker veya consumer yoğunluğunda gecikme artabilir. UI bu window'u tolere etmelidir. Kritik işlemlerde authoritative read yapılabilir.

Event Kaybı Durumunda TTL Safety Net

Event pipeline tamamen güvenilir kabul edilmemelidir. Consumer bug veya retention sorunu invalidation'ı kaçırabilir. TTL belirli süre sonra stale key'i temizler. Daha kritik namespace reconciliation job ile karşılaştırılabilir. Event success metriği ile cache stale incident'ları birlikte izlenmelidir.

CDC ile Redis Cache Senkronizasyonu

Change Data Capture database change log içindeki değişiklikleri event akışına dönüştürür. Application her write path'inde manuel cache event yayınlamak zorunda kalmaz. CDC connector değişiklikleri Kafka benzeri sisteme taşıyabilir. Cache consumer ilgili key'i invalidates veya günceller. Model güçlü olsa da eventual consistency ve schema change yönetimi devam eder.

Database Change Log

Database transaction log committed değişikliklerin güvenilir kaynağıdır. CDC bu log'u okuyarak row-level event üretebilir. Application event publish ile database commit arasındaki dual-write gap azalır. Log retention connector downtime süresini karşılamalıdır. Sensitive column'ların event'e gereksiz taşınmaması gerekir.

Change Data Capture

CDC database mutation'larını downstream sistemlere aktarır. Cache, search ve analytics aynı event stream'den faydalanabilir. Transaction order ve snapshot bootstrap dikkat gerektirir. Consumer idempotent olmalıdır. CDC cache correctness'i artırabilir fakat operasyonel olarak yeni bir distributed pipeline ekler.

Debezium

Debezium çeşitli database loglarından change event üretmek için yaygın kullanılan açık kaynak yaklaşımlardan biridir. Connector configuration hangi table ve kolonların izlendiğini belirler. Schema evolution event consumer tarafından ele alınmalıdır. Snapshot sırasında cache population özel plan isteyebilir. Production connector lag ve failure metric'leri izlenmelidir.

Kafka

Kafka CDC event'lerinin durable stream olarak taşınmasında kullanılabilir. Partition key aynı entity için order korunmasına yardımcı olur. Cache consumer gerektiğinde event'i yeniden oynatabilir. Retention recovery window sağlar. Broker operasyonu cache sisteminden bağımsız kapasite ve güvenlik gerektirir.

Cache Update/Invalidation

CDC consumer yeni row value'dan cache payload üretebilir veya yalnızca key silebilir. Delete daha basit ve schema coupling'i düşüktür. Update cache hit continuity sağlar. Query aggregate cache'lerinin hangi row change'den etkilendiğini hesaplamak zor olabilir. Böyle cache'ler kısa TTL ile yönetilebilir.

Eventual Consistency

Database commit ile CDC event'in cache'e ulaşması arasında zaman vardır. Bu window boyunca stale value görülebilir. Lag SLO olarak ölçülmelidir. Kritik read gerektiğinde database bypass edilebilir. Eventual consistency kullanıcı ve ürün davranışında açıkça kabul edilmiş olmalıdır.

Multi-Tier Caching Nedir?

Multi-tier caching veriyi kullanıcıya farklı mesafelerde birden fazla cache katmanında tutar. Application process memory L1, Redis L2, CDN veya edge ise public content için başka katman olabilir. Her seviyenin latency, kapasite ve invalidation davranışı farklıdır. Origin database son kaynak olarak kalır. Katman sayısı arttıkça hit performansı yükselirken freshness yönetimi daha dikkatli tasarlanmalıdır.

L1 Application Cache

L1 aynı process memory'sinde bulunduğu için network RTT gerektirmez. Hot key'ler için en hızlı katmandır. Capacity application memory ile sınırlıdır. Her process farklı kopya taşıdığı için invalidation problemi vardır. Kısa TTL veya Redis tracking bu riski azaltabilir.

L2 Redis

Redis bütün application replicas tarafından paylaşılan distributed cache'tir. L1 miss durumunda buraya gidilir. Data L1'e göre daha tutarlı ortak görünüm sağlar. Network latency yine vardır. Cluster ve HA topolojisi L2'nin kapasite ve availability hedeflerine göre seçilir.

L3 CDN/Edge

Public HTTP content kullanıcıya yakın edge noktalarında cache'lenebilir. Request application data center'a ulaşmadan cevaplanır. Redis üzerindeki yük de azalır. User-specific veya private response için cache control dikkatle yönetilmelidir. CDN invalidation ile Redis invalidation zinciri farklı TTL'lere sahip olabilir.

Origin Database

Bütün cache katmanları miss olduğunda authoritative database'e gidilir. Bu en pahalı path olabilir. Origin her cache katmanı failure olduğunda sistemi tamamen kaybetmeyecek kadar korunmalıdır. Concurrency limit ve circuit breaker burada önemlidir. Query optimizasyonu cache var diye ihmal edilmemelidir.

Her Katmanda Farklı TTL

L1 birkaç saniye, Redis dakikalar ve CDN başka süre kullanabilir. En dış katmanın TTL'i veri freshness limitini aşmamalıdır. Invalidation event gerekiyorsa katmanlara uygun yöntemlerle yayılır. L1 çok kısa TTL sayesinde explicit event olmadan da kabul edilebilir olabilir. Policy document her layer için freshness ve failure behavior'ını tanımlamalıdır.

L1 Local Cache + Redis Birlikte Nasıl Kullanılır?

L1 ve Redis birlikte kullanıldığında en sıcak data application memory'sinden, geri kalan shared cache'ten okunur. Bu yapı Redis network QPS'ini ciddi biçimde azaltabilir. Hot key problemlerinde özellikle etkilidir. Buna karşılık her application process stale copy taşıyabilir. L1 TTL kısa tutulmalı veya invalidation mekanizması eklenmelidir.

Process Memory

In-process cache nanosecond veya microsecond seviyesine yakın erişim sağlayabilir. Serialization format object olarak tutuluyorsa tekrar parse maliyeti de kalkar. Memory limiti process heap'iyle rekabet eder. GC behavior izlenmelidir. LRU veya size-bounded local cache kontrolsüz büyümeyi engeller.

Redis Distributed Cache

L1 miss Redis'e gider. Redis ortak L2 olarak farklı application replicas arasında cache paylaşır. Redis value L1'e kısa süre kopyalanabilir. L2 invalidation L1'e ulaşmıyorsa stale window L1 TTL ile sınırlanır. High-cardinality data yalnızca L2'de tutulabilir.

Hot Data

En sık kullanılan küçük value'lar L1 için iyi adaydır. Bütün Redis dataset'i process memory'ye kopyalamak doğru değildir. Admission hit frequency üzerinden yapılabilir. Hot set trafik değiştikçe local eviction ile uyum sağlar. Metrics L1 hit, L2 hit ve origin miss şeklinde ayrı tutulmalıdır.

Çok Kısa L1 TTL

Bir veya birkaç saniyelik local TTL bile Redis call sayısını çok azaltabilir. Staleness sınırı düşük kalır. Her process kendi expiration zamanına sahip olduğu için trafik doğal olarak dağılır. Hot key update sonrası birkaç saniye eski değer kabul edilebiliyorsa basit çözüm sunar. Daha güçlü freshness gerekiyorsa tracking eklenebilir.

Invalidation Problemi

Redis key silinse bile local memory copy yaşamaya devam edebilir. Event bus veya Redis client-side tracking local entry'yi invalidate edebilir. Connection loss durumunda local cache flush edilmelidir. Update event'in kaçırılması TTL ile sınırlanır. L1 cache'in consistency contract'ı ayrıca belgelenmelidir.

Redis Client-Side Caching Nedir?

Redis client-side caching uygulamanın local memory'sinde değer saklarken Redis'in değişiklik olduğunda invalidation bilgisi göndermesine dayanır. Redis bu özelliği Tracking mekanizmasıyla destekler. RESP3 kullanıldığında data response ve invalidation message aynı bağlantı üzerinden taşınabilir. Broadcasting veya tracked-key modları farklı memory ve message trade-off'ları sunar. Hot read workload'larında Redis'e giden network request sayısını önemli ölçüde azaltabilir.

Application Memory Cache

Client Redis'ten okuduğu bazı değerleri kendi process memory'sine koyar. Sonraki read Redis network call yapmadan local value'yu döndürür. Capacity sınırlı tutulmalıdır. Local eviction policy application tarafından yönetilebilir. Redis invalidation yalnızca coherence konusunda yardımcı olur.

Redis Tracking

Tracking server'ın client'ın okuduğu key'leri izlemesine izin verir. İlgili key değiştiğinde client invalidation mesajı alabilir. Bu yöntem server tarafında tracking metadata kullanır. Opt-in ve opt-out gibi modlar hangi key'lerin takip edildiğini kontrol eder. Client library desteği doğrulanmalıdır.

Server-Assisted Invalidation

Application kendi event sistemini kurmadan Redis değişiklik bilgisini iletebilir. Key update olduğunda local copy silinir. Sonraki read Redis'ten fresh value alır. Bu model Redis dışındaki database değişikliğini tek başına bilmez. Database mutation yine Redis key'i update veya invalidate etmelidir.

RESP3

RESP3 push-style mesajların normal data connection ile birlikte taşınmasına imkan verir. Client-side caching invalidation bunun önemli kullanım alanlarından biridir. RESP2 ile ayrı redirect connection yaklaşımı kullanılabilir. Client library protocol desteği configuration'da kontrol edilmelidir. Connection pool kullanımı tracking bağlantı modelini etkileyebilir.

Redis'e Giden Network Request'lerini Azaltmak

Hot key local memory'de bulunduğunda her read Redis'e gitmez. Network RTT ortadan kalkar. Redis server QPS'i azalır. Application memory kullanımı artar. Invalidations çok sık ise local cache faydası azalabilir.

Hot Read Workload'ları

Sık okunan ve makul sıklıkta değişen key'ler ideal adaydır. Sürekli INCR edilen global counter local cache için kötü olabilir. Product configuration iyi aday olabilir. Hit frequency local admission için kullanılabilir. Tracking invalidation rate ile local hit rate birlikte ölçülmelidir.

Redis Client-Side Caching'de Invalidation Nasıl Çalışır?

Client-side caching Redis'in client'ın ilgilendiği key değişikliklerini bildirmesi üzerine kuruludur. Default tracking modunda Redis client'ın okuduğu key'leri hatırlar. Broadcasting mode belirli prefix'lerdeki değişiklikleri daha geniş biçimde yayınlar. Client invalidation alınca local value'yu kaldırır. Invalidation connection kaybolduğunda local cache'in stale kalmaması için tamamının flush edilmesi güvenli davranıştır.

Tracked Keys

Client bir key'i okuduğunda Redis bu ilişkiyi tracking tablosunda tutabilir. Key değiştiğinde ilgili client'a invalidation gider. Server memory maliyeti tracked relationship sayısıyla artabilir. Client gerçekten cache'lemediği key'ler için gereksiz notification alabilir. Opt-in mode bu alanı daraltabilir.

Invalidation Message

Mesaj değişen key'in local copy'sinin artık kullanılmaması gerektiğini bildirir. Client entry'yi siler. Yeni value message içinde taşınmaz. Sonraki read normal Redis request ile güncel değeri alır. Message processing thread-safe olmalıdır.

Broadcasting Mode

Broadcasting mode Redis'in her client için tek tek tracked key listesi tutmasını azaltabilir. Client belirli prefix'lere abone olur. Prefix ile eşleşen herhangi bir key değiştiğinde notification alır. Gereksiz mesaj sayısı artabilir. Az sayıda iyi seçilmiş prefix ile hot namespace'lerde etkili olabilir.

Prefix-Based Tracking

Prefix user: veya catalog: gibi namespace gruplarını temsil edebilir. Çok fazla overlapping veya küçük prefix server CPU'sunu etkileyebilir. Key naming standardı bu özelliği kolaylaştırır. Tenant bazında milyonlarca prefix oluşturmak uygun değildir. Coarse namespace ile client local filter birlikte kullanılabilir.

Connection Kaybında Cache Davranışı

Invalidation channel kaybolursa client hangi key'lerin değiştiğini bilemez. Bu nedenle local cache flush edilmelidir. Reconnect sonrasında tracking yeniden kurulmalıdır. Ping veya connection health monitoring kopmayı hızlı fark etmelidir. Stale local value'yu sessizce kullanmaya devam etmek en riskli davranıştır.

Redis Pipelining Nedir?

Pipelining birden fazla bağımsız Redis command'ını her response'u beklemeden ardışık şekilde gönderip cevapları toplu olarak almaya imkan verir. Temel kazanç network RTT maliyetini her command için ayrı ödememektir. Redis server yine command'ları işler fakat socket interaction daha verimli hale gelir. Pipeline çok büyürse server response buffer ve client memory kullanımı artabilir. Batch boyutu workload ve payload üzerinden ayarlanmalıdır.

Round-Trip Time

Client command gönderir ve response'un geri gelmesini bekler. Bu gidiş dönüş süresi RTT'dir. Redis server işlemi çok hızlı olsa bile network RTT toplam latency'yi domine edebilir. Yüz command tek tek gönderildiğinde RTT yüz kez ödenir. Pipeline bu beklemeleri büyük ölçüde birleştirir.

Tek Tek Command Göndermenin Maliyeti

Application sequential olarak GET çağırıp her response'u beklerse network idle süreleri oluşur. CPU işlem yapabilecek durumda olsa bile client RTT bekler. Remote zone veya service mesh overhead'i farkı büyütebilir. N+1 Redis access pattern de application sorunudur. MGET veya pipeline değerlendirilebilir.

Batch Commands

Bir grup independent command pipeline'a eklenir. Client hepsini gönderir ve response'ları sırayla okur. Transaction semantics otomatik oluşmaz. Bir command diğerinin sonucuna bağlıysa normal pipeline yeterli olmayabilir. Lua veya transaction başka ihtiyaçlara hizmet eder.

Throughput Artışı

Daha az network round trip birim zamanda daha fazla operation yapılmasını sağlar. Redis official pipeline modeli bunun önemli nedenlerinden birinin socket I/O overhead azalması olduğunu açıklar. Server CPU daha verimli kullanılabilir. Application batch workload önemli hızlanma görebilir. End-to-end benchmark gerçek network üzerinde yapılmalıdır.

Response Buffer Memory

Pipeline command sayısı arttıkça server response'ları client okuyana kadar buffer'da tutulabilir. Dev pipeline memory pressure yaratır. Büyük payload'larla risk daha yüksektir. Binlerce veya on binlerce command kontrollü batch'lere bölünebilir. Optimum size testle belirlenmelidir.

Pipelining Ne Zaman Kullanılmalı?

Pipelining birbirinden bağımsız çok sayıda Redis operation aynı workflow içinde gerektiğinde yararlıdır. Bulk read, bulk write ve batch processing tipik kullanım alanlarıdır. Tek bir request yalnızca bir GET yapıyorsa pipeline gereksizdir. Command sonuçları birbirine bağlıysa server-side script veya başka model daha uygun olabilir. Batch size ve timeout değerleri production latency'sine göre ayarlanmalıdır.

Çok Sayıda Independent Command

Bir listedeki yüz user için farklı Redis hash field'ları okunabilir. Her request diğerinden bağımsızsa pipeline round-trip sayısını azaltır. Cluster client command'ları shard'lara uygun şekilde dağıtabilir. Cross-slot semantics kullanılan library'ye göre kontrol edilmelidir. Error response'lar batch içinde tek tek ele alınmalıdır.

Bulk Reads

Bir endpoint birçok independent key okumak zorunda kalabilir. MGET same-slot şartları uygunsa daha basit olabilir. Farklı command türleri gerekiyorsa pipeline daha esnektir. Payload toplam boyutu response latency'sini etkiler. Cache data model N+1 read yaratıyorsa model yeniden değerlendirilebilir.

Bulk Writes

Cache warming sırasında binlerce SET command pipeline ile gönderilebilir. Her command'a TTL uygulanabilir. Pipeline transaction değildir ve bazı command'lar başarısız olabilir. Retry yalnızca başarısız subset için yapılabilir. Çok büyük import'ta dedicated bulk-loading yöntemi değerlendirilebilir.

Batch Size

Batch çok küçükse RTT kazancı sınırlı kalır. Çok büyükse memory ve tail latency artar. Payload size command count kadar önemlidir. 10 bin küçük command ile 10 bin büyük value aynı değildir. Load test farklı batch size'ların throughput ve p99 etkisini ölçmelidir.

Çok Büyük Pipeline'lardan Kaçınmak

Server bütün response'ları client okumadan önce buffer'lamak zorunda kalabilir. Client da response listesi için memory kullanır. Tek dev pipeline fairness'i bozabilir. Bounded batch application backpressure'ını kolaylaştırır. Throughput az değişirken memory riski önemli ölçüde düşebilir.

MGET/MSET mi Pipelining mi?

MGET ve MSET tek command içinde birden fazla key üzerinde işlem yapar. Pipelining ise farklı Redis command'larını tek network akışında batch etmeye yarar. Cluster ortamında multi-key command'ların same-slot kısıtları önemlidir. Hash tag ilgili key'leri aynı slot'a yerleştirebilir. Data model yalnızca MGET çalışsın diye aşırı same-slot yoğunluğu yaratmamalıdır.

Multi-Key Commands

MGET birçok string key'i tek command ile okuyabilir. MSET birçok value yazabilir. Single-node Redis'te kullanımı basittir. Cluster'da key'ler farklı slot'lara düşerse command kısıtlanabilir. Cluster-aware client bazı operasyonları otomatik bölse bile semantics bilinmelidir.

Network RTT

MGET tek command olduğu için bir round trip ile birçok value döndürür. Pipeline da benzer RTT avantajı sağlar. Pipeline farklı command type'larını destekler. Server command processing davranışı farklı olabilir. Performance gerçek batch boyutuyla karşılaştırılmalıdır.

Redis Cluster Cross-Slot Kısıtı

Redis Open Source Cluster multi-key command'larda ilgili key'lerin aynı hash slot'ta olmasını gerektirebilir. Aksi durumda cross-slot error oluşur. Client key'leri slot bazında bölerek birden fazla operation yapabilir. Lua script ve transaction için de same-slot requirement önemlidir. Cluster data model baştan bu kuralı dikkate almalıdır.

Hash Tag Gereksinimi

Key içinde süslü parantezle belirlenen bölüm slot hashing için kullanılabilir. user:{123}:profile ve user:{123}:settings aynı slot'a gider. Böylece related keys multi-key operation içinde kullanılabilir. Bütün key'leri aynı tag altında toplamak cluster dağılımını yok eder. Hash tag yalnızca atomic veya multi-key locality gereken entity gruplarında kullanılmalıdır.

Redis Connection Pooling

Redis client bağlantıları her request için yeniden kurulmak yerine uzun ömürlü olarak kullanılmalıdır. TCP ve TLS connection setup maliyeti tekrar edilmemelidir. Ancak “pool” gereksinimi client library'nin concurrency modeline bağlıdır, bazı modern client'lar tek bağlantı üzerinde multiplexing veya async I/O yapabilir. Blocking command veya transaction isolation ayrı connection isteyebilir. Bu nedenle amaç çok connection açmak değil gereken kadar connection'ı güvenli biçimde yeniden kullanmaktır.

Her Request İçin Yeni Connection Açmamak

Connection setup network handshake ve gerekiyorsa TLS maliyeti taşır. Redis server da sürekli client create ve close işlemi yapar. High traffic altında bu pattern ciddi overhead yaratır. Shared client veya pool tercih edilir. Application shutdown sırasında connection'lar kontrollü kapatılmalıdır.

Pool Size

Pool size request concurrency ile Redis processing kapasitesi arasında dengelenmelidir. Daha fazla connection her zaman daha yüksek throughput vermez. Çok büyük pool Redis maximum client ve file descriptor kullanımını artırır. Blocking operation ayrı pool isteyebilir. Load test size değişikliğinin p99 ve queue wait etkisini göstermelidir.

Connection Timeout

Connection oluşturma veya borrow işlemi sonsuza kadar beklememelidir. Timeout dependency failure'ın application thread'lerini tüketmesini engeller. Çok kısa timeout normal transient latency'de gereksiz error oluşturabilir. Redis RTT ve failover behavior'a göre seçilir. Timeout metric alerting için ayrı izlenmelidir.

Idle Connection

Gereksiz binlerce idle connection server resources tüketir. Pool minimum ve maximum size ayrı tanımlanabilir. Keepalive network device timeout'larına yardımcı olabilir. Çok uzun idle connection failure sonrasında stale socket taşıyabilir. Client reconnect davranışı test edilmelidir.

Application Replica Sayısının Redis'e Etkisi

Pool size tek pod üzerinden düşünülmemelidir. Yüz pod ve pod başına elli connection toplam beş bin client demektir. Autoscaling anında connection sayısı çok hızlı yükselebilir. Redis capacity ve load balancer network limits buna göre planlanır. Connection budget deployment platformunda shared configuration olarak tutulabilir.

Connection Explosion Nedir?

Connection explosion application replica sayısı arttığında toplam Redis bağlantılarının kontrolsüz büyümesidir. Pod başına büyük pool küçük cluster'da problem görünmeyebilir. Autoscaling sırasında yüzlerce yeni process aynı anda connection açınca Redis client count ve network stack baskısı yükselir. Connection reuse ve bounded pool temel çözümdür. Failover sonrası bütün client'ların aynı anda reconnect etmesi de geçici connection explosion yaratabilir.

Pod Sayısı × Pool Size

Toplam connection basitçe instance sayısı ve instance başına connection budget üzerinden tahmin edilebilir. Horizontal scaling bu değeri doğrusal büyütür. Birden fazla Redis node varsa topology connection'ları da eklenir. Monitoring connected clients ile deployment replica sayısını aynı dashboard'da göstermelidir. Capacity review yalnızca normal replica count'u değil maksimum autoscaling değerini kullanmalıdır.

Maximum Client Sayısı

Redis ve işletim sistemi aynı anda sınırsız client kabul etmez. File descriptor limitleri ve memory per connection etkili olur. Maximum clients değerine yaklaşmak yeni connection error'larına neden olabilir. Alert yeterli erken eşikte çalışmalıdır. Gereksiz idle connection'lar azaltılmalıdır.

Autoscaling Sonrası Connection Spike

CPU spike application platformunda yeni pod'lar oluşturabilir. Hepsi aynı anda Redis'e bağlanır. Bu sırada cache cold ise request QPS de yüksek olabilir. Startup jitter ve connection backoff yoğunluğu azaltır. Warming operation'ın her replica tarafından tekrar yapılması engellenmelidir.

Pool Limitleri

Application library maksimum connection sınırı taşımalıdır. Request sayısı arttığında pool sonsuz büyümemelidir. Queue wait belirli timeout sonrası fail veya degrade olmalıdır. Blocking command normal request connection'larını uzun süre tutmamalıdır. Pool metriği active, idle ve wait count olarak izlenebilir.

Connection Reuse

Uzun ömürlü connection throughput ve latency'yi iyileştirir. Pipelining veya multiplexing aynı connection üzerinden daha fazla iş yapabilir. Connection health check fail socket'i pool'dan çıkarır. Authentication ve TLS yalnızca setup sırasında yapılır. Reuse client library'nin thread-safety kurallarına göre uygulanmalıdır.

Redis Memory Yönetimi

Redis cache capacity yalnızca key payload toplamından oluşmaz. Dataset yanında internal metadata, replication buffer, persistence süreçleri ve memory allocator overhead'i bulunur. maxmemory cache dataset için önemli sınırdır. İşletim sistemi ve background operation'lar için headroom bırakılmalıdır. Memory fragmentation RSS ile logical used memory arasında fark oluşturabilir.

maxmemory

maxmemory Redis'in cache data için kullanacağı memory sınırını belirlemeye yardımcı olur. Limit aşıldığında eviction policy devreye girer veya noeviction davranışıyla write error oluşabilir. Physical RAM'in tamamını maxmemory olarak ayarlamak güvenli değildir. Replication ve persistence buffer'ları için yer gerekir. Monitoring used memory yanında resident memory değerini de izlemelidir.

Dataset Memory

Key, value ve Redis object metadata dataset memory oluşturur. Küçük çok sayıda key metadata overhead nedeniyle beklenenden fazla alan kullanabilir. Big key farklı biçimde kapasiteyi tüketir. Serialization format value size'ı doğrudan etkiler. Key naming standard aşırı uzun prefix'lerden kaçınmalıdır.

Replication Buffer

Primary replica'lara değişiklik akışı göndermek için buffer kullanır. Replica yavaşsa buffer ihtiyacı büyüyebilir. Eviction sırasında oluşan writes de replication traffic'e dönüşebilir. Memory planında bu alan dataset'ten ayrı düşünülmelidir. Replication lag ve buffer size birlikte izlenir.

Persistence Buffer

AOF veya snapshot işlemleri sırasında background süreçleri ve copy-on-write memory ek yük oluşturabilir. Dataset büyük ve write rate yüksekse fork döneminde memory artabilir. Pure cache persistence kapalıysa bu maliyet azalır. Persistence seçimi restart recovery ve cache warming ihtiyacıyla birlikte yapılmalıdır. OOM riskine karşı OS headroom korunmalıdır.

OS Headroom

Redis process dışında kernel, network buffer ve monitoring agent'ları memory kullanır. Physical RAM'in yüzde yüzünü Redis dataset'e vermek risklidir. Persistence veya failover sırasında temporary peak oluşabilir. Container memory limit'i host memory'den ayrıca değerlendirilmelidir. Headroom gerçek peak RSS üzerinden belirlenmelidir.

Memory Fragmentation

Allocator freed memory'yi her zaman işletim sistemine hemen geri vermez. Bu nedenle Redis logical used memory düştüğü halde RSS yüksek kalabilir. Fragmentation ratio tek başına incident göstergesi değildir. Pattern sürekli büyüyorsa object size distribution incelenebilir. Restart veya allocator tuning ancak ölçülen ihtiyaç olduğunda uygulanmalıdır.

Redis Eviction Policy Nedir?

Eviction policy Redis memory limiti dolduğunda hangi key'lerin çıkarılacağını belirler. Cache workload'unda doğru policy hit rate ve origin load'u doğrudan etkiler. noeviction memory dolduğunda yeni data ekleyen command'ların hata vermesine yol açabilir. LRU ve LFU kullanım davranışına göre aday seçer. TTL odaklı veya random politikalar farklı access pattern'lerinde anlamlı olabilir.

Memory Limit Dolduğunda Ne Olur?

Yeni write Redis memory kullanımını limit üzerine çıkarabilir. Seçilen policy uygun key'leri evict ederek alan açmaya çalışır. Eviction'ın kendisi cache miss oranını yükseltir. Hiç uygun key yoksa write error oluşabilir. Application bu error'ı normal cache failure gibi güvenli biçimde ele almalıdır.

noeviction

Noeviction key'leri otomatik kaldırmaz. Memory limitine ulaşıldığında yeni data eklemeye çalışan command error dönebilir. Session veya critical state ile pure cache aynı instance'da tutuluyorsa bazen veri kaybını önlemek için düşünülür. Ancak cache population sürekli başarısız olabilir. Capacity ve application error handling buna göre tasarlanmalıdır.

LRU

Least Recently Used yakın zamanda kullanılmayan key'leri çıkarmaya çalışır. Redis bunu yaklaşık sampling yaklaşımıyla uygular. Recency hot set'in gelecekte de kullanılacağı workload'larda iyi sonuç verebilir. Scan benzeri workload cache pollution yaratabilir. Hit/miss trend'i policy'nin gerçek etkisini göstermelidir.

LFU

Least Frequently Used daha sık erişilen key'leri korumaya çalışır. Viral fakat uzun süre popüler kalan hot content için LRU'dan daha iyi olabilir. Redis approximate frequency counter kullanır ve zamanla decay uygular. Eski popüler key sonsuza kadar korunmaz. Workload değişim hızına göre LFU tuning değerlendirilebilir.

Random

Random eviction herhangi bir key'i seçebilir. Implementasyonu basit ve belirli uniform access pattern'lerinde kabul edilebilir olabilir. Strong hot set bulunan sistemde değerli key'lerin gereksiz atılmasına neden olabilir. Benchmark LRU/LFU ile karşılaştırılmalıdır. Random policy özel gerekçe olmadan varsayılan seçim yapılmamalıdır.

TTL Bazlı Eviction

Volatile TTL yaklaşımı expiration süresi olan key'ler arasından seçim yapar. volatile-ttl kalan TTL'i kısa olan key'leri tercih edebilir. Bütün key'lerde TTL yoksa policy alan açmakta sınırlı kalabilir. Pure cache instance'da allkeys policy daha basit olabilir. Session ve cache aynı Redis'te bulunuyorsa policy sonuçları özellikle dikkatle değerlendirilmelidir.

LRU ve LFU Arasındaki Fark

LRU en son ne zaman kullanıldığına, LFU ise ne kadar sık kullanıldığına odaklanır. İki model aynı hot set'i farklı biçimde koruyabilir. Ani trend değişikliklerinde recency daha hızlı tepki verebilir. Uzun süre sürekli kullanılan key'lerde frequency yararlı olabilir. Hangi policy'nin daha iyi olduğu synthetic varsayım yerine gerçek hit ratio ve origin QPS ile ölçülmelidir.

Recently Used

LRU yakın zamanda erişilen key'i sıcak kabul eder. Uzun süredir okunmayan value eviction adayı olur. Bu behavior session-like temporal locality pattern'inde iyi çalışabilir. Tek seferlik büyük scan çok sayıda key'i recent yaparak cache pollution oluşturabilir. Admission ve separate namespace bu etkiyi azaltabilir.

Frequently Used

LFU access frequency bilgisini approximate counter üzerinden değerlendirir. Sürekli kullanılan product key yüksek priority kazanır. Birkaç kez yeni okunmuş key eski hot key'i hemen dışarı atmayabilir. Counter decay workload değişimine uyum sağlar. Frequency distribution'ın güçlü olduğu sistemlerde faydalıdır.

Hot Dataset

Hot dataset toplam keyspace'in küçük fakat yoğun kullanılan bölümüdür. İdeal eviction policy bu subset'i memory'de tutar. Working set maxmemory içine sığıyorsa hit oranı yüksek kalır. Sığmıyorsa policy ne olursa olsun thrashing görülebilir. Capacity artırma veya cache admission daraltma gerekebilir.

Trafik Pattern'ine Göre Seçim

Temporal burst workload LRU'ya uygun olabilir. Stable popularity distribution LFU'dan faydalanabilir. Uniform random reads iki policy arasında daha az fark gösterebilir. Synthetic test gerçek Zipf distribution'ını taklit etmelidir. Production A/B veya canary metric policy seçimini doğrulayabilir.

Cache Thrashing Nedir?

Cache thrashing working set memory kapasitesinden büyük olduğunda değerlerin sürekli evict edilip kısa süre sonra tekrar istenmesi durumudur. Redis origin'den getirilen key'i cache'e yazar. Bunun için başka bir key evict edilir. Yeni evict edilen key hemen yeniden istenir ve döngü sürer. Sonuç düşük hit rate, yüksek origin QPS ve gereksiz Redis write yüküdür.

Key Evict Edilir

Memory pressure eviction policy bir key seçer. Bu key aslında yakın gelecekte yeniden kullanılacak olabilir. Evicted count artar. Cache value kaybolduğu için sonraki read miss olacaktır. Eviction rate normal traffic baseline ile karşılaştırılmalıdır.

Hemen Tekrar İstenir

Hot working set memory'e sığmıyorsa evicted key kısa süre sonra request alır. Origin fetch gerekir. Kullanıcı miss penalty yaşar. Hit ratio düşer. Redis cache olmasına rağmen database yükü tekrar yükselir.

Tekrar Cache'e Yazılır

Origin sonucu aynı key'i yeniden populate eder. Bu write memory limitini tekrar zorlar. Başka key eviction adayı olur. Serialization ve network işi tekrar edilir. Cache aslında sürekli veri taşıyan bir revolving door haline gelir.

Başka Key Evict Edilir

Yeni key için açılan alan başka sıcak key'i çıkarabilir. Traffic dağılımına göre zincir devam eder. LRU/LFU iyileştirme sağlayabilir ama capacity açığını tamamen çözemez. Namespace admission policy gereksiz cold data'yı cache dışında tutabilir. Memory artırmak en doğrudan çözüm olabilir.

Düşük Cache Efficiency

Hit rate ve origin offload düşer. Redis write QPS yükselir. Evicted keys sürekli artar. CPU ve network hem cache hem database tarafında gereksiz kullanılır. Bu durumda cache architecture yeniden boyutlandırılmalıdır.

Redis Serialization Performansı

Redis bytes saklar, application object'leri bu representation'a serialize eder. Format seçimi payload boyutu, CPU ve schema evolution'ı etkiler. JSON debugging açısından kolaydır. MessagePack veya Protocol Buffers daha küçük binary payload sağlayabilir. En hızlı Redis deployment bile application serialization CPU'su yüksekse beklenen endpoint kazancını göstermeyebilir.

JSON

JSON insan tarafından okunabilir ve geniş ecosystem desteğine sahiptir. Key-value object'lerde hızlı geliştirme sağlar. Field name'ler payload içinde tekrarlandığı için binary formatlardan büyük olabilir. Parsing CPU'su yüksek request rate'te belirginleşebilir. Compression ancak belirli size üzerinde anlamlı olabilir.

MessagePack

MessagePack JSON benzeri structure'ı binary ve daha compact biçimde taşıyabilir. Payload size azalabilir. Human readability düşer. Cross-language library compatibility doğrulanmalıdır. Schema discipline uygulama tarafında yine gereklidir.

Protocol Buffers

Protocol Buffers explicit schema ve compact binary representation sağlar. Cross-service contract için uygundur. Schema evolution field numbering kurallarına bağlıdır. Cache payload debugging ek tooling gerektirir. Çok küçük object'lerde complexity kazancı sınırlı olabilir.

Serialization CPU

Her cache hit deserialize gerektirebilir. Saniyede yüz bin hit CPU maliyetini büyütür. L1 object cache parse işini azaltabilir. Benchmark sadece Redis command time değil serialize ve deserialize sürelerini içermelidir. Profiling hotspot hangi formatın gerçekten kazanç sağlayacağını gösterir.

Payload Size

Daha küçük payload memory ve network kullanımını azaltır. Aynı Redis instance daha fazla key tutabilir. Cache hit latency özellikle cross-zone network'te düşebilir. Projection cache gereksiz field'ları taşımaz. Size distribution percentile olarak izlenmelidir.

Schema Evolution

Cache'te eski serialized object yeni code ile uyumsuz olabilir. Versioned key bu sorunu sadeleştirir. Backward-compatible serializer başka seçenektir. Rolling deployment sırasında iki schema aynı anda bulunabilir. Migration plan cache value formatını da kapsamalıdır.

Cache Verisi Sıkıştırılmalı mı?

Compression büyük payload'larda memory ve network tasarrufu sağlayabilir. Bunun karşılığında her read ve write CPU işi eklenir. Küçük value'larda compression header ve CPU maliyeti kazancı aşabilir. Boyut threshold kullanmak yaygın yaklaşımdır. Gerçek sıkıştırma oranı data formatına göre benchmark edilmelidir.

Büyük Payload

Yüzlerce kilobayt veya megabayt response compression için adaydır. Önce object'in gerçekten bu kadar büyük olması gerekip gerekmediği sorgulanmalıdır. Projection ve pagination daha kalıcı çözüm olabilir. Compression big-key problemini tamamen ortadan kaldırmaz. Delete ve replication yine compressed byte size üzerinde maliyet taşır.

Network Kazancı

Compressed payload Redis ile application arasında daha az byte taşır. Cross-zone veya multi-region bağlantıda kazanç büyüyebilir. Local same-host network'te CPU cost daha baskın olabilir. Bytes-in ve bytes-out metric değişimi ölçülmelidir. Network saturation varsa compression daha değerli hale gelir.

Memory Kazancı

Redis compressed byte string'i daha küçük saklar. Aynı maxmemory içinde daha büyük working set tutulabilir. Eviction oranı düşebilir. Application value'yu her hit'te decompress etmek zorundadır. L1 decompressed cache CPU tekrarını azaltabilir.

Compression CPU Cost

Compression write sırasında, decompression read sırasında CPU tüketir. High-hit cache'te decompress cost sürekli tekrar eder. Fast codec ve compression level dengesi önemlidir. Application CPU Redis tasarrufundan daha pahalı hale gelebilir. End-to-end profiling gerekir.

Boyut Threshold'u

Cache wrapper örneğin yalnızca belirli byte değerinin üzerindeki payload'ları sıkıştırabilir. Threshold benchmark ile bulunmalıdır. Content type sıkıştırılabilirlik oranını etkiler. Zaten compressed image veya binary data tekrar sıkıştırılmamalıdır. Payload metadata codec bilgisini güvenli biçimde taşımalıdır.

Redis Sentinel Nedir?

Redis Sentinel clustering kullanılmayan Redis topolojilerinde yüksek erişilebilirlik sağlar. Primary ve replica instance'ları izler. Primary failure olduğunda quorum ve majority kurallarına göre failover süreci başlatabilir. Uygun replica yeni primary olarak seçilir. Sentinel-aware client güncel primary adresini Sentinel'den öğrenerek bağlantısını yeniler.

Primary

Normal write işlemleri primary üzerinde gerçekleşir. Replicas primary data stream'ini takip eder. Sentinel primary health'ini düzenli kontrol eder. Failure tespit edildiğinde tek Sentinel kararı yeterli değildir. Quorum ve failover authorization süreci split-brain riskini azaltmaya çalışır.

Replica

Replica primary'den data alır. Failover sırasında uygun replica promote edilebilir. Replication asynchronous olduğu için en son write'ların kaybı tamamen imkansız değildir. Cache workload'unda bu risk source database'den rebuild edilebildiği için daha kabul edilebilir olabilir. Session veya durable state için farklı değerlendirme gerekir.

Monitoring

Sentinel instance'lar Redis node'larının ulaşılabilirliğini izler. Tek Sentinel yanlış network görüşüne sahip olabilir. Birden fazla Sentinel bağımsız failure domain'lerinde çalıştırılmalıdır. Redis resmi guidance sağlam Sentinel deployment için en az üç Sentinel önerir. Monitoring Sentinel quorum health'ini ayrıca kontrol etmelidir.

Quorum

Quorum kaç Sentinel'in primary'nin down olduğunda anlaşması gerektiğini tanımlar. Failover'ın gerçekten yapılması için ayrıca Sentinel majority authorization gerekir. Bu iki kavram aynı değildir. Yanlış quorum configuration failover hassasiyetini etkiler. Network partition testleri gerçek behavior'ı doğrulamalıdır.

Automatic Failover

Failure doğrulandıktan sonra Sentinel bir replica'yı primary'ye promote eder. Diğer replicas yeni primary'yi takip edecek şekilde reconfigure edilir. Client yeni endpoint'i öğrenmelidir. Failover sırasında kısa error ve timeout penceresi normaldir. Retry jitter bu süreçte reconnect storm'u azaltır.

Sentinel-Aware Client

Client doğrudan sabit primary IP'ye bağlanmamalıdır. Sentinel API üzerinden current primary discovery yapar. Failover sonrası yeni adresi öğrenir. Client library'nin Sentinel desteği production öncesi test edilmelidir. Connection pool eski primary connection'larını temizleyebilmelidir.

Redis Cluster Nedir?

Redis Cluster keyspace'i birden fazla primary node arasında hash slot üzerinden dağıtarak horizontal sharding sağlar. Aynı zamanda replicas üzerinden node failure durumunda failover yeteneği sunar. Redis Open Source Cluster keyspace'i 16.384 hash slot'a böler. Her primary belirli slot grubundan sorumludur. Dataset veya throughput tek node sınırını aştığında Cluster önemli seçenek haline gelir.

Horizontal Sharding

Key'ler tek server yerine farklı primary node'lara dağıtılır. Memory ve CPU kapasitesi yatay büyür. Client key'in slot'una göre doğru node'a yönlenir. Cluster-aware client topology bilgisini tutar. Cross-key operation'lar slot locality nedeniyle ayrıca tasarlanmalıdır.

16.384 Hash Slot

Redis Cluster toplam 16.384 slot kullanır. Key CRC tabanlı hesapla slot'a eşlenir. Resharding key'leri tek tek bütün cluster yerine slot grupları üzerinden taşımayı kolaylaştırır. Slot sayısı node sayısından bağımsız sabittir. Client topology map hangi slot'un hangi primary'de olduğunu gösterir.

Primary Nodes

Her primary belirli slot'lar için write authority taşır. Cluster kapasitesi primary sayısıyla büyüyebilir. Data distribution slot count açısından dengeli olsa bile traffic dağılımı dengesiz olabilir. Hot key tek primary'yi zorlayabilir. Node başına memory ve CPU ayrı izlenmelidir.

Replica Nodes

Replica primary'nin slot data'sını kopyalar. Primary failure durumunda cluster replica'yı promote edebilir. Read scaling için stale read kabul edilen durumlarda replica routing kullanılabilir. Replication asynchronous olduğu için consistency trade-off vardır. Replica sayısı availability ve infrastructure cost arasında dengelenir.

Automatic Failover

Cluster node failure'ını gossip ve voting mekanizmalarıyla değerlendirir. Uygun replica primary rolüne geçebilir. Client MOVED veya topology change bilgisine uyum sağlamalıdır. Failover sırasında transient errors için bounded retry uygulanır. Cluster failure testleri application client behavior'ını da kapsamalıdır.

Horizontal Capacity

Yeni primary node eklenip slot'lar reshard edildiğinde memory ve throughput kapasitesi artırılabilir. Tek hot key sorunu bununla otomatik çözülmez. Big key reshard sırasında taşıma maliyeti oluşturabilir. Capacity planning hottest shard üzerinden yapılmalıdır. Cluster operational overhead tek instance'a göre daha yüksektir.

Sentinel mi Redis Cluster mı?

Sentinel ve Redis Cluster aynı probleme aynı ölçekte çözüm değildir. Sentinel sharding olmadan primary-replica topolojisine high availability sağlar. Cluster dataset ve throughput'u birden fazla primary arasında dağıtırken failover yeteneği de sunar. Tek node memory ve CPU kapasitesi yeterliyse Sentinel daha sade olabilir. Horizontal scaling ihtiyacı varsa Cluster doğal seçim haline gelir.

Tek Node'a Sığan Dataset

Dataset ve QPS tek Redis primary'nin kapasitesi içindeyse sharding gerekmeyebilir. Replica ve Sentinel availability ihtiyacını karşılayabilir. Operasyon ve client topology daha basittir. Vertical scaling belirli noktaya kadar yeterli olabilir. Growth projection düzenli gözden geçirilmelidir.

High Availability

Sentinel özellikle non-clustered Redis için HA sağlar. Cluster da replicas ve failover mekanizmasıyla availability sunar. İki modelde de client topology change'e uyum sağlamalıdır. Cache application transient failover error'ını tolere etmelidir. Multi-AZ placement failure domain'i azaltır.

Horizontal Scaling

Dataset tek node RAM sınırını aştığında Sentinel kapasiteyi shard etmez. Redis Cluster keyspace'i primary node'lara dağıtır. Throughput farklı execution nodes arasında paylaşılır. Cross-slot data model kısıtları eklenir. Application client'ın cluster-aware olması gerekir.

Operational Complexity

Cluster resharding, slot mapping ve cross-slot behavior gibi ek operasyon kavramları getirir. Sentinel daha sade topology taşır ancak failover ve quorum yine iyi yönetilmelidir. Managed deployment operasyon yükünü azaltabilir. Team capability teknoloji seçiminde önemlidir. Gereksiz erken sharding hata yüzeyini büyütür.

Karar Matrisi

Tek node capacity yeterli ve HA gerekiyorsa Sentinel düşünülür. Horizontal memory veya QPS scaling gerekiyorsa Cluster tercih edilir. Çok-key atomic operation yoğun workload Cluster data modelini zorlayabilir. Hot key sorunu varsa Cluster tek başına çözüm değildir. Availability, capacity ve data access pattern birlikte karar vermelidir.

Redis Cluster Hash Slot Mantığı

Redis Cluster key'i doğrudan node adına hash etmez, önce sabit slot alanına eşler. Bu abstraction resharding'i yönetilebilir kılar. Slot farklı primary'ye taşındığında key mapping topology üzerinden değişir. Cluster-aware client MOVED yönlendirmelerini işleyebilir. Hash tag aynı slot'ta tutulması gereken related keys için kontrollü istisna sağlar.

Key Hashing

Key string'inden CRC tabanlı hash hesaplanır. Sonuç 16.384 slot alanına map edilir. Aynı key her zaman aynı slot'u hedefler. Hash tag varsa yalnızca parantez içindeki bölüm hesaplamaya dahil edilir. Uniform random key'ler slot'lara genellikle dengeli dağılır.

Slot Distribution

Primary node'lara slot aralıkları atanır. Node sayısı arttığında slot'lar yeniden paylaştırılabilir. Equal slot count equal memory veya QPS garantisi değildir. Value size ve access frequency farklı olabilir. Balancing metric key count dışında memory ve traffic'i de değerlendirmelidir.

Resharding

Slot'lar bir node'dan diğerine taşınabilir. Migration sırasında bazı multi-key operation'lar geçici TRYAGAIN benzeri durumlarla karşılaşabilir. Client retry behavior güvenli olmalıdır. Big key slot migration süresini uzatabilir. Resharding peak traffic dışında planlanabilir.

Node Ekleme

Yeni primary cluster'a katılır ancak başlangıçta slot taşımıyorsa trafik almaz. Existing node'lardan slot transfer edilir. Replica placement ayrıca planlanır. Capacity artışı reshard tamamlandıkça gerçekleşir. Client topology refresh yeni node'u öğrenir.

Node Çıkarma

Primary çıkarılmadan önce sahip olduğu slot'lar başka node'lara taşınmalıdır. Replica ve failover coverage korunmalıdır. Removal sırasında capacity headroom yeterli olmalıdır. Client stale topology bilgisini yenilemelidir. Operasyon monitoring ve rollback planıyla yapılmalıdır.

Redis Hash Tags Nedir?

Hash tags key içinde belirli substring'i slot hesaplamasının kaynağı yapar. Aynı tag'i paylaşan key'ler aynı hash slot'a yerleşir. Bu özellik MGET, MSET, Lua veya transaction gibi same-slot gerektiren operasyonları destekler. Yanlış kullanılırsa çok sayıda key tek shard'a yığılabilir. Tag yalnızca gerçek co-location ihtiyacı olan küçük key gruplarında kullanılmalıdır.

{user:123}

{user:123}:profile ve {user:123}:settings aynı tag'i taşır. İki key aynı slot'a gider. User entity üzerinde multi-key operation kolaylaşır. Milyonlarca user farklı tag kullandığı için dağılım devam eder. Bütün user'lar için tek {user} tag kullanmak ise kötü dağılım yaratır.

Related Keys

Aynı transaction veya script içinde birlikte işlenen key'ler related kabul edilebilir. Hash tag onları aynı node'a toplar. Bu locality network coordination ihtiyacını azaltır. Çok büyük entity group hot slot yaratabilir. Data model co-location ile balance arasında sınır koymalıdır.

MGET/MSET

Cluster'da MGET ve MSET gibi multi-key command'lar same-slot requirement taşıyabilir. Hash tag bu requirement'ı karşılar. Client farklı slot key'leri kendi tarafında split edebilir fakat atomicity değişir. API davranışı bilinmelidir. Basit performans uğruna data distribution bozulmamalıdır.

Lua

Redis Cluster Lua script içinde kullanılan key'lerin aynı slot'ta olması gerekir. Hash tag script'in ilgili entity key'lerini co-locate eder. Script key isimlerini gizli şekilde üretmemelidir. Required keys çağrı sırasında açık olmalıdır. Uzun Lua execution Redis latency'sini etkileyebileceği için kısa tutulmalıdır.

Cross-Slot Hatalarını Önlemek

Key naming helper same-slot olması gereken keys için ortak tag üretir. Integration test keyslot değerlerini doğrulayabilir. Random string concatenation cross-slot error'lara yol açabilir. Migration sırasında eski ve yeni key formatı dikkatle yönetilir. Cluster-aware architecture bu kuralları development aşamasında görünür yapmalıdır.

Redis Cluster'da Hot Shard Problemi

Cluster slot sayısı dengeli olsa bile traffic veya memory eşit dağılmayabilir. Bir shard daha fazla hot key taşıyabilir. Büyük value'lar memory imbalance yaratabilir. Hot key tek node üzerinde yoğunlaşır. Resharding bazı sorunları azaltırken tek key içindeki yoğunluğu parçalayamaz.

Dengesiz Key Dağılımı

Hash tags yanlış kullanılırsa çok sayıda key aynı slot'ta kalabilir. Key count node'lar arasında farklılaşır. Memory ve QPS de dengesiz olur. Slot histogram kontrol edilmelidir. Key naming değişikliği uzun migration gerektirebilir.

Hot Key

Tek key saniyede çok yüksek request alır. Slot'u başka node'a taşımak yalnızca yükün yerini değiştirir. L1 caching veya key replication gerekir. Read replica routing bazı senaryolarda yardımcı olabilir. Write-heavy hot key daha özel data model isteyebilir.

Memory Imbalance

Key sayısı aynı olsa bile value boyutları farklı olabilir. Bir shard maxmemory'e erken ulaşır. Eviction o shard'da başlar. Cluster genel memory yüzdesi normal görünebilir. Shard-level used memory alert zorunludur.

Shard CPU

Bir node O(N) command veya yüksek QPS nedeniyle CPU saturation yaşayabilir. Diğer nodes idle kalır. Overall cluster CPU ortalaması sorunu gizler. Max CPU ve command rate node bazında izlenir. Resharding normal key workload'u dağıtabilir.

Resharding'in Sınırları

Resharding slot'ları node'lar arasında taşır. Tek hot key slot içindeki dominant trafik olmaya devam eder. Çok related keys aynı hash tag ile bağlıysa birlikte taşınırlar. Big key migration operasyonu pahalı olabilir. Data model ve local cache çözümü bazen infrastructure scaling'den daha etkilidir.

Read Replica Kullanmak Cache Performansını Artırır mı?

Replica read routing bazı read-heavy workload'larda primary üzerindeki yükü azaltabilir. Ancak Redis cache zaten düşük latency hedeflediği için consistency ve topology maliyeti dikkatle değerlendirilmelidir. Replicas asynchronous olduğu için stale read mümkündür. Cluster'da replica read kullanmak client'ın stale data kabul ettiğini açıkça belirtmesini gerektirebilir. Hot key read dağıtımında faydalı olsa da L1 cache daha düşük network maliyeti sunabilir.

Read Scaling

Read request'ler primary yerine replicas arasında dağıtılabilir. Toplam read throughput artabilir. Replica sayısı network ve memory maliyeti getirir. Write yine primary'de gerçekleşir. Client routing policy healthy replica seçmelidir.

Replication Lag

Replica primary write'ını kısa gecikmeyle alır. Yoğun write veya network problemi lag'i büyütebilir. Cache value update sonrası replica eski value döndürebilir. Lag metriği read routing kararına dahil edilebilir. Strong freshness gereken read primary'den yapılmalıdır.

Stale Reads

Cache zaten kontrollü staleness kabul ediyorsa replica lag ek window yaratabilir. TTL policy bu gecikmeyi hesaba katmalıdır. User mutation sonrası read kendi yeni state'ini görmeyebilir. Sticky primary read kısa süre kullanılabilir. Business requirement en fazla kabul edilen staleness'i belirlemelidir.

Consistency Gereksinimi

Public catalog için küçük replica lag kabul edilebilir. Permission veya critical state için uygun olmayabilir. Data sınıfları read routing policy taşıyabilir. Tek global “read replica kullan” flag'i yetersizdir. Application wrapper consistency mode üzerinden route seçebilir.

Replica Read Routing

Cluster-aware client replicas'ı topology üzerinden bilir. Read-only mode veya library option kullanılabilir. Failure sırasında client primary'ye fallback yapabilir. Replica load dengesizliği izlenmelidir. Read routing benchmark gerçek network topology üzerinde yapılmalıdır.

Redis Failover Sırasında Uygulama Ne Yapmalıdır?

Failover application açısından kısa connection error, timeout veya topology değişimi olarak görünür. Client yeniden bağlanmalı ve yeni primary bilgisini öğrenmelidir. Retry yapılabilir fakat bütün pod'ların aynı anda agresif retry yapması yeni yük dalgası oluşturur. Exponential backoff ve jitter kullanılmalıdır. Cache dependency mümkünse kısa süre database fallback veya stale value ile degrade olabilmelidir.

Connection Failure

Existing TCP connection kapanabilir veya command timeout olabilir. Application bunu cache miss ile aynı kabul etmemelidir. Dependency error metriği ayrı tutulur. Circuit breaker failure rate'i izler. Request criticality'ye göre fallback seçilir.

Client Reconnect

Client kontrollü backoff ile yeni bağlantı kurar. Tight loop reconnect Redis ve network üzerinde ek yük yaratır. Authentication ve TLS yeniden yapılır. Connection pool stale sockets'i temizler. Reconnect success time failover recovery SLO'sunun parçasıdır.

Topology Refresh

Cluster client slot map'i yenilemelidir. Sentinel client yeni primary endpoint'i öğrenmelidir. MOVED veya connection error topology refresh tetikleyebilir. Refresh bütün request thread'leri tarafından bağımsız yapılmamalıdır. Client library'nin behavior'ı chaos test ile doğrulanmalıdır.

Retry

GET gibi idempotent cache read tekrar denenebilir. Write command retry duplicate semantics açısından dikkat ister. Retry sayısı bounded olmalıdır. Deadline kalan süreyi aşmamalıdır. Application genel request timeout'u dependency retry'lerini sınırlandırmalıdır.

Retry Storm'u Önlemek

Yüz pod aynı anda failover fark ederse binlerce retry oluşabilir. Jitter reconnect zamanlarını dağıtır. Circuit breaker bir süre cache call'larını kesebilir. Stale local cache temporary response sağlar. Origin fallback da ayrıca rate-limited olmalıdır.

Database Fallback

Redis read başarısızsa origin'e gitmek basit görünür. Ancak bütün cache traffic bir anda database'e dönebilir. Concurrency limit ve load shedding olmadan bu fallback database'i çökertir. Low-priority endpoint degraded response verebilir. Cache failure testleri database survival'ı özellikle doğrulamalıdır.

Redis Cache Çökerse Uygulama Çalışmaya Devam Etmeli mi?

Pure cache kullanıyorsanız çoğu durumda evet, ancak sınırsız database fallback ile değil. Cache source of truth değilse uygulama veriyi origin'den yeniden üretebilir. Bu path daha yavaş olduğu için kullanıcı experience degrade olabilir. Origin kapasitesi korunmazsa cache failure database failure'a dönüşür. Cache'in dependency seviyesi her namespace için açıkça sınıflandırılmalıdır.

Cache'in Dependency Seviyesi

Product catalog cache optional dependency olabilir. Session data Redis'te tek kopyaysa critical dependency haline gelir. Rate limiter fail behavior ayrı karar ister. Bütün Redis kullanımlarını aynı availability sınıfında değerlendirmek doğru değildir. Architecture inventory state türünü belirtmelidir.

Graceful Degradation

Cache yokken bazı features daha az ayrıntılı response dönebilir. Expensive recommendations geçici kapatılabilir. Stale local value kullanılabilir. User kritik işini tamamlamaya devam eder. Degradation mode monitoring ve incident communication içinde görünür olmalıdır.

Database Fallback

Critical read origin'den alınabilir. Fallback concurrency sınırlıdır. Query timeout normal cache-miss path'ten daha kısa tutulabilir. Database pool rezerv kapasitesi korunur. Her request'in otomatik origin'e gitmesi engellenir.

Fallback'ın Database'i Çökertme Riski

Cache normalde yüzde 95 traffic offload ediyorsa database kalan yüzde 5 için boyutlandırılmış olabilir. Redis kaybında yük yirmi katına çıkabilir. Fallback circuit ve token bucket bunu sınırlar. Critical endpoint önceliklendirilir. Chaos test gerçek kapasite sınırını gösterir.

Load Shedding

Sistem taşıyamayacağı işi erken reddeder. Bu yaklaşım bütün request'lerin yavaşlayıp timeout olmasından daha kontrollüdür. Low-priority read endpoint önce kısıtlanabilir. Retry davranışı client'a açıkça belirtilir. Shed rate incident severity metriği olarak izlenebilir.

Circuit Breaker Redis Cache Katmanında Nasıl Kullanılır?

Circuit breaker Redis sürekli timeout veya connection error verdiğinde uygulamanın her request'te aynı başarısız dependency'yi denemesini engeller. Belirli hata eşiğinde circuit açılır. Cache çağrısı kısa devre edilerek alternatif path uygulanır. Belirli bekleme sonrası sınırlı half-open denemeler recovery'yi kontrol eder. Origin fallback de kapasite koruması olmadan çalıştırılmamalıdır.

Redis Timeout

Cache timeout normal endpoint deadline'dan kısa olmalıdır. Redis performans için kullanılıyorsa uzun saniyeler beklemek anlamsızdır. Timeout spike circuit failure counter'ını artırır. Network ve server latency ayrı izlenir. Çok agresif timeout normal transient variation'da yanlış circuit açabilir.

Circuit Open

Error rate threshold aşılırsa cache call geçici olarak yapılmaz. Application hızlı fallback kararına geçer. Redis connection storm azalır. Origin rate limit devreye girer. Circuit state bütün instance'larda aynı olmak zorunda değildir.

Cache Bypass

Open circuit sırasında request doğrudan alternatif path kullanır. Bu path stale local cache, default response veya controlled database fetch olabilir. Her request database'e gitmemelidir. Endpoint priority dikkate alınır. Bypass metric incident süresince izlenir.

Half-Open Recovery

Bekleme süresinden sonra az sayıda request Redis'i test eder. Başarılıysa circuit kapanır. Hata devam ederse tekrar açılır. Bütün traffic bir anda geri gönderilmez. Recovery sırasında cache hâlâ cold olabilir ve warming gerekebilir.

Origin Koruması

Circuit cache'i korurken database'i unutmamalıdır. Cache bypass için ayrı semaphore veya rate limit kullanılır. Origin saturation metric'i fallback admission kararını etkiler. Low-priority request erken fail olabilir. Böylece bir dependency arızası ikinci dependency'yi düşürmez.

Cache Warming Nedir?

Cache warming kullanıcı trafiği gelmeden önce yüksek olasılıkla ihtiyaç duyulacak key'leri cache'e yüklemektir. Deployment, restart veya versioned namespace değişiminde cold miss miktarını azaltır. Warming bütün dataset'i preload etmek anlamına gelmez. Popular key'ler historical traffic üzerinden seçilebilir. Origin QPS bounded tutulmalıdır.

Deployment Öncesi Populate

Yeni cache schema deploy edilmeden önce v2 key'ler background job ile oluşturulabilir. Application switch olduğunda hit oranı yüksek başlar. Eski v1 key'ler TTL ile kalır. Warming işinin başarısız olması deploy'u her zaman bloklamak zorunda değildir. Critical hot set completion threshold belirlenebilir.

Popular Keys

Top product, homepage ve reference data warming için önceliklidir. Long-tail key'leri preload etmek memory israfı yaratır. Traffic logs popularity listesi sağlar. Seasonal campaign key'leri deployment öncesi ayrıca eklenebilir. Hot set zamanla değiştiği için warming listesi dinamik tutulabilir.

Scheduled Prewarming

Cache TTL planlı olarak bitecekse background job önceden refresh edebilir. Sabah trafik spike'ından önce belirli data hazırlanabilir. Job origin capacity'yi aşmamalıdır. Tek instance work leader olmalıdır. Failure normal cache-aside path ile telafi edilebilir.

Cold Start

Redis restart veya yeni cluster başlangıcında cache boş olabilir. Uygulama doğrudan full traffic alırsa origin yükü patlayabilir. Staged traffic ramp-up ve warming birlikte kullanılmalıdır. Pure cache persistence bu süreyi azaltmak için opsiyonel olabilir. Cold-start load test production planının parçası olmalıdır.

Tüm Dataset'i Preload Etmeme

Cache'in amacı aktif working set'i hızlı tutmaktır. Hiç okunmayacak milyonlarca key'i preload etmek memory ve database I/O israfıdır. Eviction daha başlamadan cache thrashing oluşabilir. Top-N popularity veya recent access listesi kullanılabilir. Admission gerçek traffic'in kalan key'leri doğal şekilde doldurmasına izin verir.

Deployment Sonrası Cache Avalanche Nasıl Önlenir?

Yeni deployment cache key formatını değiştirdiğinde bütün traffic cold miss yaşayabilir. Versioned key schema güvenli migration sağlar fakat warming gerektirir. Canary deployment yeni namespace'e küçük traffic göndererek cache'i kademeli doldurabilir. Traffic ramp-up origin QPS'i kontrol eder. Rate limiting database'i beklenmeyen miss dalgasından korur.

Versioned Keys

Yeni code eski payload ile uyumsuzsa yeni namespace kullanır. Schema correctness korunur. Fakat başlangıç hit rate sıfıra yaklaşabilir. Hot set prewarm edilir. Memory geçici olarak eski ve yeni key'leri birlikte taşır.

Staged Warming

Warming batch'leri origin capacity'ye göre aşamalı çalıştırılır. Popüler key'ler önce yüklenir. Başarı oranı ve latency izlenir. Database CPU yüksekse job yavaşlatılır. Bütün cache'i tek anda doldurmak yeni avalanche oluşturabilir.

Canary Deployment

Küçük application replica grubu yeni cache version'ını kullanır. İlk traffic cache'i kademeli populate eder. Origin impact gözlemlenir. Sorun yoksa rollout genişletilir. Eski application'lar eski cache namespace'inde çalışmaya devam eder.

Traffic Ramp-Up

Yeni version'a geçen request yüzdesi kontrollü artırılır. Cache hit oranı yükseldikçe daha fazla traffic verilebilir. Origin CPU ve pool wait threshold'ları gate olarak kullanılabilir. Otomatik rollback mümkündür. Full switch tek adım yerine ölçüme dayanır.

Origin Rate Limiting

Miss sayısı beklenenden fazla olsa bile database fetch concurrency sınırlandırılır. Bazı request'ler stale veya temporary response alabilir. Critical path için ayrı quota ayrılır. Rate limit dynamic origin health'e göre değişebilir. Bu katman cache migration hatasını database outage'a dönüşmekten korur.

Redis'te Slow Command Problemi

Redis düşük latency sağlasa da her command sabit maliyetli değildir. Büyük collection üzerinde çalışan O(N) operation uzun sürebilir. Command execution uzadığında aynı execution path üzerindeki diğer request'ler bekleyebilir. Big key ve yanlış command seçimi p99 latency spike oluşturur. SLOWLOG ve command complexity bilgisi bu problemleri bulmanın temel araçlarıdır.

Redis'in Event Loop Davranışı

Redis event-driven request processing kullanır ve command execution süresinin kısa olması büyük önem taşır. Modern sürümlerde çeşitli I/O ve multi-thread performans geliştirmeleri bulunsa da uzun süren command yine ilgili shard üzerindeki diğer işleri etkileyebilir. Bu nedenle “Redis memory'de, her command hızlıdır” varsayımı yanlıştır. Command complexity production data size ile birlikte değerlendirilmelidir. Büyük collection operation'ları benchmark edilmelidir.

O(N) Operasyonlar

N collection element sayısını temsil ediyorsa büyüdükçe command latency de artabilir. Development'ta yüz elementle hızlı olan işlem production'da milyon elementle risklidir. Redis command documentation complexity bilgisini sunar. SLOWLOG gerçek problem command'larını gösterir. Data model operation'ı küçük bounded parçalara ayırabilir.

Büyük Collection'lar

Dev list, set veya hash üzerinde full traversal pahalıdır. Single key cluster'da tek shard üzerinde kalır. Partial field operations mümkünse tercih edilir. Pagination veya SCAN-like iteration kullanılabilir. Collection size metriği top-N big keys şeklinde izlenebilir.

Blocking Latency

Uzun command tamamlanana kadar diğer operations bekleyebilir. Bu p99 spike olarak görünür. Application tarafında Redis timeout artar. Client retry yaparsa load daha da yükselir. Slow command root cause çözülmeden yalnızca timeout büyütmek problemi gizler.

Slow Log

Redis SLOWLOG belirlenen execution threshold'u aşan commands'ı kaydeder. Ölçüm network I/O süresini değil command execution süresini temel alır. Bu nedenle server-side CPU hotspot'u bulmakta değerlidir. Max log length sınırlı tutulur. Slowlog düzenli olarak merkezi monitoring'e aktarılabilir.

Production'da KEYS Neden Kullanılmamalıdır?

KEYS belirli pattern'e uyan key'leri bulmak için bütün keyspace'i tarar. Büyük production Redis'te bu işlem uzun sürebilir ve diğer commands'ın latency'sini artırabilir. Redis resmi operasyon rehberleri production keyspace traversal için SCAN kullanılmasını önerir. Debugging amacıyla küçük ortamda KEYS pratik olabilir. Application business logic hiçbir zaman KEYS'e dayanacak şekilde tasarlanmamalıdır.

Tüm Keyspace'i Taramak

KEYS database'deki anahtar alanını bir kerede dolaşır. Milyonlarca key olduğunda CPU süresi büyür. Result payload da çok büyük olabilir. Cluster'da behavior topology'ye göre ek maliyet taşır. Deterministic key tasarımı business lookup için tarama ihtiyacını ortadan kaldırmalıdır.

Blocking Risk

Uzun keyspace scan diğer request'lerin processing süresini etkileyebilir. Normal GET latency bir anda yükselir. Client timeout ve retry storm oluşabilir. Tek operasyon tüm cache performansını bozabilir. Production ACL ile KEYS kullanımını sınırlandırmak değerlendirilebilir.

Büyük Dataset

Dataset büyüdükçe KEYS maliyeti doğrusal olarak artar. Küçük staging test riskin gerçek boyutunu göstermez. Key sayısı milyonlara ulaştığında debugging yaklaşımı değişmelidir. Metrics ve namespace inventory key scan yerine kullanılabilir. Administrative scan düşük COUNT ve controlled rate ile yapılabilir.

SCAN Alternatifi

SCAN keyspace'i incremental olarak iterasyonla dolaşır. Her call küçük bir bölüm döndürür ve cursor ile devam edilir. Full operation yine toplamda bütün keyspace'i tarayabilir ancak tek uzun blocking command riskini azaltır. Duplicate results ihtimali semantiğe göre ele alınmalıdır. Production administrative tooling SCAN üzerine rate-limited kurulmalıdır.

Redis SLOWLOG Nasıl Kullanılır?

SLOWLOG server içinde uzun command execution'larını yakalamak için kullanılır. Threshold configuration microsecond cinsinden hangi commands'ın kaydedileceğini belirler. SLOWLOG network transfer süresini içermez. Bu nedenle application latency yüksek fakat slowlog boşsa network veya client-side sorun araştırılmalıdır. Big key ve O(N) command tespitinde oldukça değerlidir.

Slow Command Detection

Log entry command, execution time ve metadata içerebilir. Top slow command type'ları düzenli analiz edilir. Aynı key pattern tekrar ediyorsa data model problemine işaret edebilir. Sensitive arguments log handling politikasına göre redacted edilmelidir. Detection incident sonrası değil sürekli monitoring içinde bulunmalıdır.

Threshold

Threshold çok yüksek olursa orta seviyeli latency problemleri kaçırılır. Çok düşük olursa log gereksiz kalabalık olur. Redis deployment'ın latency SLO'suna göre seçilmelidir. Peak dönem ve normal dönem distribution incelenebilir. Configuration değişikliği kalıcı config'e de yazılmalıdır.

Execution Time

SLOWLOG ölçümü Redis command'ın server içindeki execution süresini gösterir. Network RTT ve response transfer süresi dahil değildir. Bu ayrım root cause analizinde önemlidir. Büyük payload hızlı command olsa bile application tarafında yavaş görünebilir. Client timing ile slowlog birlikte okunmalıdır.

CPU Hotspot

Uzun command server CPU'sunu meşgul edebilir. Aynı node üzerinde p99 yükselir. Cluster'da yalnızca bir shard etkilenebilir. Command frequency ve duration çarpımı toplam CPU impact'i gösterir. Data model veya command selection değiştirilmelidir.

Query Optimization

Redis tuning de database query tuning gibi gerçek workload verisiyle yapılmalıdır. Slow O(N) command daha küçük range'e bölünebilir. Büyük structure parçalanabilir. Precomputed value kullanılabilir. Optimization sonrası SLOWLOG entry ve p99 latency değişimi ölçülmelidir.

Redis Latency Monitoring

Redis latency tek average değerle izlenmemelidir. p50 normal request deneyimini, p95 ve p99 tail behavior'ı gösterir. Network, application serialization ve Redis server processing ayrı ölçülmelidir. Latency spike failover, slow command, memory pressure veya network congestion kaynaklı olabilir. Application-side timer kullanıcıya en yakın gerçek Redis dependency süresini sağlar.

P50

Median latency request'lerin yarısının altında kaldığı değerdir. Normal base performance için kullanışlıdır. Tail spike'ları göstermez. Network zone değişikliği p50'de açıkça görülebilir. Version upgrade baseline karşılaştırmasında değerlidir.

P95

Request'lerin yüzde 95'inin altında kaldığı latency değeridir. Daha nadir yavaşlamaları görünür yapar. Pool contention veya occasional network delay burada çıkabilir. SLO için p95 kullanılabilir. High traffic sistemde kalan yüzde 5 yine büyük kullanıcı sayısı temsil eder.

P99

P99 tail latency problemi için daha hassastır. Slow command veya failover etkisi burada belirginleşebilir. Hot shard diğer node'lardan daha yüksek p99 üretebilir. Application endpoint p99 ile Redis dependency p99 korelasyonu incelenmelidir. Alert normal variance'ı göz önünde bulundurmalıdır.

Latency Spike

Kısa süreli spike deployment veya background operation ile ilişkili olabilir. Timestamp correlation root cause'u hızlandırır. Snapshot, resharding veya large delete gibi event'ler loglanmalıdır. Network packet loss da aynı semptomu yaratabilir. Spike boyunca slowlog ve CPU birlikte incelenir.

Redis vs Network Latency

Server command 100 mikro saniye sürerken application 3 milisaniye ölçebilir. Fark network, queue ve client processing'dir. SLOWLOG yalnızca server execution'ı gösterir. Cross-zone deployment RTT'yi yükseltir. Redis'i application'a network olarak yakın konumlandırmak önemlidir.

Application-Side Measurement

Cache wrapper command başlamadan ve response geldikten sonra timer tutabilir. Hit, miss ve error tag'leri eklenir. Serialization süresi ayrı span olabilir. Trace origin fallback'i aynı request içinde gösterir. Sampling yüksek traffic'te telemetry overhead'i sınırlar.

Redis İçin İzlenmesi Gereken Temel Metrikler

Redis monitoring cache effectiveness, memory health, connection ve command throughput alanlarını birlikte kapsamalıdır. Keyspace hits ve misses cache davranışını gösterir. Eviction ve expiration farklı nedenlerle key kaybını anlatır. Memory fragmentation kapasite sorununa sinyal verebilir. Connected clients ve operations per second trafik değişimini görünür hale getirir.

Keyspace Hits

Redis'in mevcut key'den cevap verdiği read sayısını gösterir. Tek başına application semantic hit rate ile aynı olmayabilir. L1 cache Redis'e hiç gitmediği için bu metric'te görünmez. Namespace ayrımı application telemetry'de yapılabilir. Trend traffic değişimiyle normalize edilmelidir.

Keyspace Misses

Redis key bulamadığında miss counter artar. Cold start veya eviction spike bunu yükseltir. Negative cache uygulaması bazı origin miss'leri Redis hit'e dönüştürür. Miss count origin query count ile bire bir olmayabilir çünkü coalescing vardır. İki metriğin farkı stampede prevention başarısını gösterebilir.

Evicted Keys

Memory limit nedeniyle çıkarılan key sayısını gösterir. Sürekli yüksek değer working set capacity problemine işaret edebilir. Policy yanlış seçilmiş olabilir. Cache hit oranıyla korelasyon incelenir. Normal peak sırasında kısa eviction ile sürekli thrashing ayrılmalıdır.

Expired Keys

TTL nedeniyle expiration sayısını gösterir. Yüksek olması tek başına kötü değildir. Aynı anda büyük spike oluşması avalanche riskidir. Deployment veya warming batch zamanıyla karşılaştırılır. Jitter sonrası distribution'ın daha dengeli olması beklenir.

Memory Usage

Used memory maxmemory'e yaklaşma oranı izlenmelidir. Dataset, overhead ve RSS ayrı anlam taşır. Node/shard bazlı maksimum değer önemlidir. Cluster average hot shard memory sorununu gizleyebilir. Capacity alert eviction başlamadan önce uyarı vermelidir.

Fragmentation

RSS ile logical allocated memory arasındaki fark allocator behavior hakkında fikir verir. Kısa süreli yüksek oran normal olabilir. Sürekli büyüyen RSS kapasite riskidir. Big-key delete pattern fragmentation'ı etkileyebilir. Automatic restart çözüm olarak kullanılmadan önce root cause incelenmelidir.

Connected Clients

Application scale ile client count birlikte büyür. Failover veya autoscaling spike oluşturabilir. Maximum clients değerine yaklaşmak alert üretmelidir. Çok sayıda idle connection pool yanlış yapılandırmasına işaret edebilir. Client name tagging service bazında attribution sağlar.

Operations per Second

Ops/sec Redis throughput'unun temel göstergesidir. Traffic artışı ve cache pattern değişikliği burada görünür. Pipeline application request sayısından daha fazla operation üretebilir. Hot shard node-specific ops/sec ile bulunabilir. CPU ve network utilization ile birlikte yorumlanmalıdır.

Yüksek Trafik Redis Alert'leri

Alert sistemi yalnızca Redis tamamen down olduğunda çalışmamalıdır. Hit rate düşüşü origin overload'un erken sinyali olabilir. P99 latency artışı kullanıcı etkisi başlamadan önce dependency sorununu gösterebilir. Memory pressure eviction spike ile birleştiğinde cache thrashing riski yükselir. Connection, failover ve replication lag için de açık operational threshold'lar belirlenmelidir.

Hit Rate Düşüşü

Normal yüzde 95 hit oranı yüzde 70'e düşerse origin QPS birkaç kat artabilir. Deployment, key version veya eviction ilk şüphelilerdir. Alert global değil namespace bazında çalışabilir. Seasonal traffic pattern baseline'a dahil edilmelidir. Hit rate tek başına değil origin CPU ile korele edilmelidir.

P99 Latency Artışı

Tail latency slow command veya network saturation gösterebilir. Bir node'da artıyorsa hot shard araştırılır. Bütün node'larda artıyorsa infrastructure veya client-side sorun olabilir. SLOWLOG ve network RTT aynı dashboard'da bulunmalıdır. Alert birkaç kısa spike yerine sürdürülen pencere kullanabilir.

Memory Pressure

Used memory maxmemory'e yaklaştığında warning verilmelidir. Eviction başlamadan capacity action alınabilir. RSS physical RAM'e yaklaşması daha kritik olabilir. Persistence operation geçici peak yaratabilir. Node bazlı alarm cluster average yerine kullanılmalıdır.

Eviction Spike

Ani eviction cache hit oranını düşürebilir. Yeni large-key deployment veya traffic growth sebep olabilir. Policy değişikliği de etkiler. Evicted keys rate origin miss rate ile korele edilir. Sustained spike capacity review tetikler.

Connection Spike

Autoscaling veya reconnect storm connected clients'i hızla artırabilir. Redis maksimum client limitine yaklaşabilir. Application deployment event'leriyle correlation yapılır. Pool size yanlışsa kalıcı yüksek connection görülür. Backoff ve connection reuse düzeltme sağlar.

Failover

Failover olayı yüksek severity operational event'tir. Application error rate ve recovery time izlenir. Replica promotion başarılı olsa bile stale read veya kısa data loss ihtimali değerlendirilir. Client topology refresh süresi ölçülür. Tekrarlayan failover infrastructure instability göstergesidir.

Replication Lag

Lag replica'nın primary değişikliklerinin gerisinde kaldığını gösterir. Read replica kullanılıyorsa stale data etkisi vardır. Failover anında data freshness riski artar. Network veya write throughput root cause olabilir. Lag threshold workload consistency requirement'ına göre seçilir.

Redis Cache SLO Nasıl Belirlenir?

Redis cache SLO yalnızca availability yüzdesinden oluşmamalıdır. p99 latency, error rate, hit rate ve origin offload birlikte sistem hedefini tanımlar. Failover recovery time da high-availability topolojisinin gerçek değerini gösterir. Cache optional dependency ise application SLO Redis SLO'dan daha yüksek olabilir. Graceful degradation bu farkı mümkün kılar.

Availability

Redis başarılı command oranı ölçülebilir. Planned maintenance ve failover behavior tanımlanır. Optional cache outage application outage olmak zorunda değildir. Cluster veya Sentinel availability hedefi destekler. Multi-region requirement ayrı SLO taşıyabilir.

P99 Latency

Cache'in amacı hızlı erişim olduğu için tail latency SLO kritiktir. Örneğin application aynı region içinde belirli düşük-milisaniye hedef belirleyebilir. Payload size ve command type sınıflandırılmalıdır. Big-key command normal GET ile aynı SLO'da değerlendirilmemelidir. Threshold gerçek network koşullarından türetilir.

Cache Hit Rate

Namespace-specific hit rate target belirlenebilir. Catalog yüzde 95, personalized feed daha düşük hedef taşıyabilir. High hit rate freshness pahasına elde edilmemelidir. SLO violation origin offload metriğiyle doğrulanır. New deployment warmup period ayrıca tanımlanabilir.

Error Rate

Timeout, connection ve command error ayrı izlenir. Client-side circuit open durumları da dependency error metric'ine dahil edilebilir. Error budget operasyon riskini yönetir. Cache write error read error kadar user impact yaratmayabilir. Command sınıfı bazında severity farklı olabilir.

Origin Offload Ratio

Cache olmasaydı origin'e gidecek read sayısıyla gerçek read sayısı karşılaştırılır. Bu metric cache'in altyapı değerini doğrudan gösterir. Hit rate L1 ve CDN dahil bütün katmanlarda ayrı hesaplanabilir. Offload düşüşü database capacity planını etkiler. SLO business traffic growth ile yeniden kalibre edilmelidir.

Failover Recovery Time

Failure başladıktan normal error ve latency seviyesine dönene kadar süre ölçülür. Sentinel detection, replica promotion ve client reconnect bu sürenin parçalarıdır. Cluster topology refresh de eklenir. Chaos test bu metriği gerçekçi biçimde üretir. SLO yalnızca infrastructure node'un geri gelmesini değil application recovery'yi temel almalıdır.

Redis Load Test Nasıl Yapılır?

Redis load test gerçek application workload'una benzemediğinde yüksek ops/sec sayısı fazla anlam taşımaz. Key distribution, read/write oranı, payload size ve concurrency production'a yakın olmalıdır. Hot key, TTL expiration ve cache miss senaryoları ayrıca denenmelidir. Cluster topology ve network RTT aynı olmalıdır. Test Redis server yanında database fallback path'ini de kapsamalıdır.

Gerçekçi Key Distribution

Production traffic genellikle uniform random değildir. Küçük key subset'i trafiğin çoğunu alabilir. Zipf benzeri distribution hot-key riskini ortaya çıkarır. Test key count production working set'e yakın olmalıdır. Tek milyon unique random key gerçek hit rate behavior'ını temsil etmeyebilir.

Read/Write Ratio

Cache workload yüzde 95 read ve yüzde 5 write olabilir. Session veya rate limiter daha yüksek write oranı taşır. Test gerçek oranı kullanmalıdır. Eviction metadata ve replication write load'dan etkilenir. P99 iki operation türü için ayrı raporlanmalıdır.

Payload Size

On byte value ile benchmark yapmak yüz kilobaytlık production JSON'u temsil etmez. Network ve serialization cost büyüklüğe bağlıdır. Size distribution percentile olarak modellenmelidir. Big-key outlier ayrıca test edilir. Compression varsa client CPU dahil edilmelidir.

Concurrent Clients

Gerçek application replica ve connection sayısı simüle edilmelidir. Tek benchmark process farklı network behavior gösterebilir. Connection pool limitleri test edilir. Autoscaling spike senaryosu ayrı çalıştırılır. Maximum clients ve server CPU izlenir.

Pipeline Length

Bulk workload farklı pipeline batch değerleriyle denenir. Throughput arttıkça response buffer ve tail latency gözlemlenir. Çok büyük batch fairness'i bozabilir. Cluster shard distribution pipeline behavior'ını etkiler. Optimum value tek sayı değil workload'a özgüdür.

Hot-Key Scenario

Traffic'in büyük bölümü tek veya birkaç key'e yönlendirilir. Shard CPU ve network saturation izlenir. L1 cache olmadan ve L1 ile karşılaştırma yapılabilir. Failover sırasında hot key behavior'ı ayrıca test edilir. Cluster toplam capacity'sine bakmak yerine hot node limiti bulunur.

TTL Expiration Scenario

Binlerce key aynı TTL ile expire edilerek avalanche behavior gözlenebilir. Jitter eklenip tekrar test edilir. Popüler key hard expiration stampede yaratır. Single-flight ve stale refresh origin QPS'i ne kadar azalttığı ölçülür. Database fallback survival bu testin önemli sonucudur.

Yalnızca redis-benchmark Sonuçlarına Güvenilmeli mi?

Hayır, redis-benchmark Redis server'ın belirli synthetic command yükünde kapasitesini görmek için faydalıdır ancak gerçek application path'ini temsil etmez. Serialization, network topology, cache miss ve origin database davranışı testin dışında kalabilir. Production key distribution uniform olmayabilir. Client library ve connection pool ek etkiler yaratır. Son karar uçtan uca load test ile verilmelidir.

Synthetic Benchmark

Synthetic test kontrollü ve karşılaştırılabilir baseline sağlar. Version veya hardware kıyaslamasında değerlidir. Ancak gerçek business flow'u sadeleştirir. Hit rate ve data freshness semantics yoktur. Sonuç kapasite üst sınırı olarak bile dikkatle yorumlanmalıdır.

Application Serialization

Benchmark raw bytes gönderirken uygulama JSON veya protobuf parse ediyor olabilir. CPU bottleneck Redis dışında oluşabilir. Compression ek maliyet getirir. Cache wrapper tracing ve logging yapabilir. End-to-end profiler gerçek time distribution'ı gösterir.

Network RTT

Local benchmark loopback üzerinde çok düşük RTT görür. Production application başka node veya zone'dadır. Service mesh ve TLS latency ekleyebilir. Aynı ops/sec ulaşılmayabilir. Load generator production topology'ye benzer konumda çalışmalıdır.

Realistic Keyspace

Uniform random key access LRU/LFU behavior'ını gerçekçi göstermeyebilir. Hot set ve long tail birlikte modellenmelidir. Dataset maxmemory'e yakın büyüklüğe getirilmelidir. Eviction davranışı ancak böyle ortaya çıkar. Big-key distribution ayrıca eklenir.

Cache Miss

Redis benchmark çoğunlukla origin fallback'i ölçmez. Gerçek uygulamada miss latency database yüzünden çok daha yüksektir. Stampede duplicate origin fetch yaratabilir. Miss ratio farklı değerlerde test edilmelidir. Cache yüzde 100 hit varsayımı resilience testini anlamsız hale getirir.

Database Fallback

Redis kapatıldığında application database'e dönebilir. Bu path kapasite testinin zorunlu parçasıdır. Origin pool limitleri ve load shedding doğrulanır. Database'in ne kadar traffic taşıyabildiği bulunur. Cache outage sırasında SLO'nun nasıl degrade olduğu ölçülür.

End-to-End Load Test

Gerçek client request application gateway üzerinden geçer. Redis hit, miss, database ve response serialization aynı testte bulunur. p95 ve p99 user latency ölçülür. Infrastructure metrics trace ID ile ilişkilendirilebilir. Production rollout kararı bu teste daha fazla güvenmelidir.

Cache Failure Testleri

Cache failure testleri happy-path performansından daha önemlidir çünkü Redis'in koruduğu büyük traffic bir anda origin'e dönebilir. Redis process kapatma, network partition ve failover senaryoları uygulanmalıdır. Cold cache ve latency injection application fallback davranışını gösterir. Memory pressure eviction problemine dayanıklılık test edilir. En önemli sonuç database'in bu olaylar sırasında ayakta kalıp kalmadığıdır.

Redis'i Kapatmak

Test environment'ta Redis primary tamamen durdurulur. Application timeout ve circuit behavior izlenir. Sentinel veya Cluster failover varsa recovery ölçülür. Pure cache fallback database'e kontrollü gitmelidir. Error rate ve user impact kaydedilir.

Network Partition

Redis process sağlıklı olsa bile application network üzerinden ulaşamayabilir. Connection timeout ve retry behavior bu durumu yönetmelidir. Partial partition yalnızca bazı pods'u etkileyebilir. Cluster topology farklı views oluşturabilir. Chaos tooling gerçek network failure'ı daha iyi simüle eder.

Failover

Primary deliberately fail edilir. Replica promotion süresi ölçülür. Client reconnect ve topology refresh doğrulanır. Retry storm gözlemlenir. Failover sonrası cache hit rate ve data freshness tekrar kontrol edilir.

Cold Cache

Bütün cache key'leri boş başlangıç olarak simüle edilir. Traffic normal QPS'e yükseltilir. Database load ve connection pool izlenir. Warming ve coalescing'in etkisi ölçülür. Sistem warmup süresince kabul edilen SLO içinde kalmalıdır.

Latency Injection

Redis tamamen down yerine yavaş olduğunda farklı bir failure oluşur. Uzun timeout request thread'lerini tutabilir. Circuit breaker threshold test edilir. Tail latency daha tehlikeli olabilir. Network proxy ile kontrollü delay eklenebilir.

Memory Pressure

Dataset maxmemory'e kadar doldurulur. Eviction policy davranışı gerçek traffic altında izlenir. Critical key'lerin beklenmedik şekilde evict olup olmadığı görülür. Noeviction ise write error path test edilir. RSS ve fragmentation ayrıca ölçülür.

Database Survival

Bütün testlerin sonunda origin'in ayakta kalması temel başarı kriteridir. Cache failure nedeniyle database collapse oluyorsa fallback tasarımı eksiktir. Rate limit ve load shedding ayarlanır. Critical endpoint capacity reserve edilir. Recovery cache tekrar geldiğinde ani refresh storm oluşturmamalıdır.

Redis Güvenliği

Redis performans katmanı olsa da güvenlik gereksinimleri azaltılmamalıdır. Instance public internet'e doğrudan açılmamalıdır. Network segmentation, authentication, ACL ve TLS defense-in-depth sağlar. Credential rotation uygulama deployment sürecine dahil edilmelidir. Cache içinde kişisel veya hassas veri tutuluyorsa access policy ana database kadar kontrollü olmalıdır.

Public Internet'e Açmamak

Redis private network içinde application tarafından erişilebilir tutulmalıdır. Public port exposure ciddi risk oluşturur. Firewall veya security group yalnızca gerekli source'lara izin vermelidir. Protected mode tek başına network isolation yerine geçmez. Managed endpoint kullanılsa bile public access policy dikkatle incelenmelidir.

TLS

TLS application ile Redis arasındaki trafiği şifreler. Cross-host ve multi-tenant infrastructure'da önemlidir. Connection setup CPU ve latency maliyeti connection reuse ile azaltılır. Certificate validation kapatılmamalıdır. Rotation client reconnect behavior'ıyla test edilmelidir.

Authentication

Redis client identity doğrulaması yapılmalıdır. Shared anonymous access kullanılmamalıdır. Credential secret manager üzerinden application'a verilir. Source repository içine yazılmaz. Authentication error monitoring deployment config sorununu hızlı bulur.

ACL

ACL kullanıcıların hangi commands ve key patterns'e erişebileceğini sınırlar. Application yalnızca ihtiyaç duyduğu command kategorilerini almalıdır. Administrative KEYS veya FLUSHALL gibi commands normal runtime user'da kapatılabilir. Service bazında ayrı credentials kullanılabilir. Least privilege incident etkisini azaltır.

Least Privilege

Cache reader yalnızca gerekli namespace ve read commands'a erişebilir. Writer farklı permission taşıyabilir. Monitoring user administrative fakat read-only command set kullanabilir. Credential compromise bütün cluster'ı silme yetkisi vermemelidir. Permission review düzenli yapılmalıdır.

Network Segmentation

Redis yalnızca application subnet veya trusted network'ten erişilebilir olmalıdır. Environment'lar birbirinden ayrılmalıdır. Development credential production'a erişmemelidir. Multi-tenant infrastructure gerekirse ayrı instance veya network boundary kullanabilir. Firewall change audit edilmelidir.

Credential Rotation

Secret süresiz aynı kalmamalıdır. Dual-credential geçişi zero-downtime rotation sağlayabilir. Client pool eski connection'ları zamanla yeniler. Rotation failure rollback planı taşır. Credential value log veya trace içine yazılmamalıdır.

Cache ve Session Aynı Redis'te Tutulmalı mı?

Evict edilebilir cache ile kullanıcı session state aynı durability ve eviction requirement'ına sahip değildir. Cache key kaybolduğunda origin'den tekrar üretilebilir. Session key kaybolduğunda kullanıcı logout olabilir veya işlem state'i kaybedebilir. Aynı instance'da eviction policy iki workload arasında çatışabilir. Kritik sistemlerde ayrı Redis deployment veya en azından güçlü resource isolation daha güvenli olabilir.

Cache Eviction

Cache için allkeys-lru veya LFU normal davranış olabilir. Memory dolduğunda düşük değerli entries çıkarılır. Session aynı keyspace'te ise yanlışlıkla session da evict olabilir. Volatile policy bile TTL kullanan session'ları hedefleyebilir. Workload separation bu riski ortadan kaldırır.

Session Data'nın Tek Kopya Olması

Session başka source'tan kolay rebuild edilemiyorsa Redis artık pure cache değildir. Persistence ve HA requirement artar. Eviction kabul edilemez hale gelebilir. Authentication availability Redis availability'ye bağlanır. State classification architecture kararını değiştirmelidir.

Farklı Eviction Gereksinimleri

Cache agresif eviction isterken session noeviction isteyebilir. Tek Redis instance tek memory policy ile yönetildiğinde conflict oluşur. Separate databases logical separation sağlasa bile aynı maxmemory ve process kaynaklarını paylaşabilir. Fiziksel instance isolation daha güçlü olabilir. Managed service planı bu ayrımı destekleyebilir.

Namespace İzolasyonu

En azından key prefix'leri farklı tutulmalıdır. ACL farklı service'lerin key alanını sınırlandırabilir. Metrics namespace usage'ını ayrı gösterebilir. Ancak namespace memory eviction isolation sağlamaz. Criticality farkı büyüdükçe ayrı deployment düşünülmelidir.

Ayrı Instance Gereksinimi

Session ve cache farklı availability veya persistence SLO taşıyorsa ayrı instance anlamlıdır. Cache failure session'ı etkilemez. Memory scaling bağımsız yapılır. Operasyon maliyeti artar. Risk ve traffic büyüklüğü bu maliyeti haklı çıkarabilir.

Redis Persistence Cache İçin Gerekli mi?

Pure cache verisi origin'den yeniden üretilebildiği için persistence zorunlu değildir. Persistence kapatıldığında restart sonrası cold-cache yükü oluşur. RDB veya AOF recovery sırasında cache'in daha hızlı geri gelmesine yardımcı olabilir. Bunun karşılığında disk I/O, fork veya log maliyeti eklenir. Seçim cache warming kapasitesi ve restart sonrası origin'in ne kadar yük taşıyabildiğine göre yapılmalıdır.

Pure Cache

Redis kaybolduğunda correctness bozulmuyorsa pure cache'tir. Persistence kapalı kullanım mümkün olabilir. Restart hızlıdır fakat dataset boştur. Database fallback ve warming güvenli olmalıdır. Session veya unique business state aynı instance'a eklenmemelidir.

Rebuildable Data

Product veya configuration source database'den yeniden okunabilir. Warming popüler subset'i geri getirir. Long-tail traffic doğal population yapar. Rebuild süresi origin capacity ile sınırlıdır. Çok pahalı computation cache'inde persistence daha değerli olabilir.

RDB

RDB belirli anların snapshot'ını disk üzerinde tutar. Restart'ta büyük cache'i tekrar yüklemeye yardımcı olabilir. Snapshot aralığı nedeniyle en yeni cache changes kritik değildir. Background snapshot operation memory ve disk etkisi taşır. Pure cache için avantaj cold-start süresidir.

AOF

AOF write commands'ı append log içinde saklar. Daha yüksek durability sağlar. Pure cache için çoğu zaman gereksiz olabilir. AOF rewrite disk ve memory işi oluşturur. Cache durable state taşıyorsa ihtiyaç yeniden değerlendirilir.

Restart Süresi

Büyük dataset persistence'tan yüklenirken startup süresi uzayabilir. Persistence yoksa server hemen boş başlayabilir fakat origin yükü artar. Hangisinin daha iyi olduğu traffic ve warming kapasitesine bağlıdır. Readiness probe cache'in hangi aşamada traffic alacağını kontrol edebilir. Staged ramp-up recovery'yi güvenli hale getirir.

Cache Warming ile Persistence Karşılaştırması

Warming yalnızca hot subset'i yükleyerek daha küçük başlangıç dataset'i oluşturabilir. Persistence geçmişte cold olmuş bütün key'leri de geri getirebilir. Bunun karşılığında origin warming read load oluşturur. High-cost origin ve uzun hot-set build süresinde snapshot avantajlı olabilir. İki yaklaşım birlikte de kullanılabilir.

Kubernetes Üzerinde Redis Cache

Kubernetes üzerinde Redis çalıştırmak stateful network identity, storage ve availability konularını doğru yönetmeyi gerektirir. StatefulSet stable pod kimliği sağlayabilir. Persistence gerekiyorsa Persistent Volume kullanılır. Sentinel veya Cluster topology pod placement failure domain'leriyle uyumlu olmalıdır. PodDisruptionBudget ve anti-affinity planlı bakımın bütün replicas'ı aynı anda düşürmesini engellemeye yardımcı olur.

StatefulSet

StatefulSet pod'lara stable identity ve ordered lifecycle sağlar. Redis replica veya cluster node isimlendirmesinde faydalıdır. Service discovery ile node adresleri oluşturulur. Rolling update topology awareness gerektirir. Operator kullanılacaksa behavior ve upgrade policy iyi anlaşılmalıdır.

Persistent Volume

Pure cache persistence kullanmıyorsa PV zorunlu olmayabilir. RDB veya AOF tutulacaksa stable volume gerekir. Storage class latency snapshot performance'ını etkiler. Pod başka node'a taşındığında volume attach süresi recovery'yi uzatabilir. Persistence ihtiyacı cache classification üzerinden verilmelidir.

Sentinel

Sentinel pod'ları bağımsız failure domain'lerine yayılmalıdır. Üç Sentinel aynı worker node'da bulunursa node failure quorum'u etkileyebilir. Anti-affinity yardımcı olur. Application Sentinel service discovery kullanır. NetworkPolicy gerekli port iletişimine izin vermelidir.

Redis Cluster

Cluster primary ve replica pod'ları node veya zone'lara dengeli yerleştirilir. Cluster bus ve client ports doğru network policy almalıdır. Pod IP değişimi topology management gerektirir. Operator bunu otomatikleştirebilir. Resharding resource request ve disruption planıyla yapılmalıdır.

Pod Anti-Affinity

Primary ile replica aynı physical node'da tutulmamalıdır. Node failure ikisini birden kaybetmemelidir. Zone-aware placement daha güçlü dayanıklılık sağlar. Çok katı affinity küçük cluster'da scheduling problemine yol açabilir. Infrastructure capacity buna göre planlanmalıdır.

PodDisruptionBudget

PDB planned eviction sırasında minimum available pods sayısını korumaya yardımcı olur. Node maintenance bütün replicas'ı aynı anda taşımamalıdır. PDB gerçek application quorum requirement'ına göre ayarlanır. Unplanned failure'ı engellemez. Upgrade runbook failover ve resharding behavior'ını ayrıca test etmelidir.

Managed Redis mi Self-Hosted Redis mi?

Managed ve self-hosted seçenekler aynı Redis semantics'ini farklı operasyon sorumluluklarıyla sunar. Managed model patching, failover ve backup operasyonunun önemli kısmını hizmet katmanına bırakabilir. Self-hosted model daha fazla kontrol ve bazı durumlarda daha düşük altyapı maliyeti sağlayabilir. Ancak uzman ekip zamanı da maliyet hesabına dahil edilmelidir. Security, scaling ve vendor dependency ihtiyaçları kararın ana girdileridir.

Operasyonel Yük

Self-hosted model upgrades, monitoring ve failover runbook'larını kurumun yönetmesini gerektirir. Managed hizmet bu görevlerin önemli bölümünü otomatikleştirebilir. Uygulama tarafındaki cache design sorumluluğu yine kurumda kalır. Stampede veya bad key model managed service tarafından çözülmez. Team capability maliyet hesabının parçasıdır.

High Availability

Managed ürün hazır multi-zone topology sağlayabilir. Self-hosted Sentinel veya Cluster doğru placement ile aynı hedefe ulaşabilir. Failover SLO ve test süreci iki modelde de önemlidir. Provider SLA application availability garantisi değildir. Client reconnect behavior yine test edilmelidir.

Backup

Pure cache backup gerektirmeyebilir. Session veya başka critical state Redis'te tutuluyorsa requirement değişir. Managed hizmet snapshot workflow sunabilir. Self-hosted backup storage ve restore testini kurum yönetir. Backup varlığı restore'un gerçekten çalıştığı anlamına gelmez.

Patching

Redis security ve bug fix sürümleri düzenli uygulanmalıdır. Managed platform rollout işini azaltabilir. Self-hosted upgrade staging ve failover planı ister. Client compatibility kontrol edilir. Major version performans değişiklikleri load testten geçmelidir.

Scaling

Managed service vertical veya horizontal scaling workflow sağlayabilir. Self-hosted Cluster resharding ekip tarafından yönetilir. Hot key infrastructure scale ile çözülmeyebilir. Memory ve throughput metrics scaling trigger olmalıdır. Cost ve operational risk birlikte değerlendirilmelidir.

Maliyet

Managed fiyat altyapıdan yüksek görünebilir fakat operasyon zamanı dahil edilmelidir. Self-hosted hardware ve engineer on-call maliyeti vardır. Cache memory pahalı resource olabilir. Compression ve admission policy gereksiz capacity ihtiyacını azaltabilir. TCO en az yıllık perspektifle hesaplanmalıdır.

Vendor Lock-In

Standart Redis protocol ve common commands portability sağlar. Proprietary features kullanıldıkça migration maliyeti artabilir. Cluster semantics ve module feature'ları sağlayıcılar arasında farklılaşabilir. Cache wrapper platform-specific API'yi sınırlandırabilir. Lock-in tek başına kötü değildir, alınan operasyon değerine göre değerlendirilmelidir.

Multi-Region Redis Cache

Multi-region cache tasarımında temel hedef kullanıcı request'ini uzak bölgedeki Redis'e göndermemektir. Region-local cache düşük RTT sağlar. Data replication asynchronous olabilir ve staleness yaratır. Global invalidation event bölgeler arasında gecikebilir. Region failure sırasında başka bölgeye traffic yönlendirildiğinde cache warmup ve source-of-truth erişimi planlanmalıdır.

Region-Local Cache

Her region kendi Redis cache'ini taşıyabilir. User request local cache'e gider. Cross-region RTT ortadan kalkar. Cache values region'lar arasında birebir aynı anda güncellenmeyebilir. TTL ve event invalidation bu eventual consistency'yi sınırlar.

Replication

Redis deployment modeline bağlı olarak region'lar arasında data replication yapılabilir. WAN latency ve network partition behavior önemlidir. Pure cache'te application-level event invalidation daha basit olabilir. Cross-region replication write cost'u artırır. Active-active gereksinim veri türüne göre değerlendirilmelidir.

Network Latency

Bir kıtadan diğer kıtaya Redis GET yapmak in-memory avantajını network RTT'ye kaybettirebilir. Region-local placement bu nedenle önemlidir. Application ve cache aynı veya yakın failure zone'da tutulabilir. Cross-zone cost da yüksek QPS'te önemli olabilir. Trace network segment latency'sini görünür yapmalıdır.

Eventual Consistency

Region A'da update olduktan sonra Region B cache'i kısa süre eski kalabilir. Event propagation latency ölçülür. Critical read source database'e yönlendirilebilir. User session bölge değiştirdiğinde stale state riski düşünülmelidir. Product freshness SLO global network gerçekleriyle uyumlu olmalıdır.

Active-Active

Birden fazla region aynı anda write kabul ediyorsa conflict resolution gerekir. Pure cache için region-local rebuild daha basit olabilir. Shared mutable state Active-Active Redis çözümleriyle yönetilebilir ancak semantics veri type'ına bağlıdır. Network partition conflict behavior anlaşılmalıdır. Bu model yalnızca gerçek multi-writer ihtiyacında kullanılmalıdır.

Region Failure

Traffic başka region'a yönlendirildiğinde hedef cache kapasitesi ani artışı karşılamalıdır. Yeni user cohort için key'ler cold olabilir. Warming ve origin rate limit devreye girer. Connection ve cluster capacity failover traffic'i hesaba katmalıdır. Disaster recovery test bunu gerçekçi biçimde simüle etmelidir.

Multi-Tenant Redis Cache

Multi-tenant cache'te key identity tenant bilgisini doğru taşımalıdır. Aksi halde farklı müşterilerin verileri çakışabilir. Noisy neighbor büyük veya hot tenant'ın bütün Redis kaynaklarını tüketmesiyle ortaya çıkar. Quota ve ayrı namespace yönetimi yardımcı olur. Güçlü security isolation gereken müşteriler için ayrı instance veya cluster gerekebilir.

Tenant Prefix

Key örneğin tenant:42:product:10 yapısında olabilir. Aynı product ID farklı tenant'larda çakışmaz. Tenant identifier hashing ile anonymize edilebilir. Cluster hash tag kullanımında prefix sırası dağılımı etkileyebilir. Key helper standardization zorunludur.

Key Isolation

ACL key patterns service veya tenant erişimini sınırlandırmaya yardımcı olabilir. Application authorization yine asıl güvenlik katmanıdır. Shared Redis memory bütün tenant'lar arasında kaynak paylaşır. Bug yanlış prefix üretirse data leak riski vardır. Integration test cross-tenant key access'i kontrol etmelidir.

Noisy Neighbor

Bir tenant yüksek QPS veya büyük cache data üretebilir. Diğer tenant'ların eviction ve latency değerleri etkilenir. Namespace metric tenant bazında kullanım gösterir. Quota veya admission limit uygulanabilir. Büyük enterprise tenant ayrı shard veya deployment'a taşınabilir.

Per-Tenant Quota

Redis native global maxmemory tenant başına doğrudan eşit quota anlamına gelmez. Application key admission ve size accounting ile limit uygulayabilir. Managed platform farklı isolation seçenekleri sunabilir. Hard quota eviction strategy gerektirir. Tenant plan ve contract ile uyumlu olmalıdır.

Hot Tenant

Bir tenant aynı key'leri çok yoğun okuyabilir. Global cache hit rate yüksek olsa da shard hotspot oluşur. L1 local cache ve key replication yardımcı olabilir. Tenant workload ayrı cluster'a taşınabilir. Cost attribution capacity planning'i kolaylaştırır.

Security Isolation

Shared cache encryption-at-rest ve network policy tek başına tenant row isolation sağlamaz. Key construction ve authorization birlikte güvenli olmalıdır. Çok yüksek compliance requirement fiziksel ayrım isteyebilir. Secrets cache'e açık biçimde yazılmamalıdır. Audit ve incident scope tenant boundary'yi gözetmelidir.

Rate Limiting ile Redis Cache Birlikte Nasıl Kullanılır?

Redis cache ve rate limiting farklı amaçlara hizmet eder ancak yüksek trafikte birbirini tamamlar. Cache database QPS'i azaltır. Rate limiter özellikle cache miss veya abuse durumunda origin'e ulaşan request sayısını sınırlar. Counter ve expiration Redis üzerinde atomic biçimde yönetilebilir. Fixed window, sliding window ve token bucket farklı trafik davranışları sunar.

Database Koruması

Cache miss request'leri için origin concurrency sınırlanabilir. Redis down olduğunda stricter rate limit devreye girebilir. Critical user işlemleri ayrı quota alır. Rate limit application edge'inde uygulanırsa database'e gereksiz request hiç ulaşmaz. Limit state failure behavior ayrıca tasarlanmalıdır.

Fixed Window

Belirli zaman dilimindeki request sayısı counter ile tutulur. Uygulaması basittir. Window sınırında iki bucket birleşerek kısa burst oluşturabilir. Düşük riskli limitlerde yeterli olabilir. TTL counter cleanup sağlar.

Sliding Window

Sliding window son belirli süre içindeki request'leri daha düzgün değerlendirir. Sorted set veya approximate counter teknikleri kullanılabilir. Memory ve command cost fixed window'dan yüksektir. High traffic'te bounded implementation gerekir. User ve IP cardinality kapasiteyi etkiler.

Token Bucket

Token bucket belirli hızla token yeniler ve kısa burst'e kontrollü izin verir. Atomic update için Lua veya uygun server-side command kombinasyonu kullanılabilir. Distributed instances aynı Redis state'ini paylaşır. Clock ve expiry behavior test edilmelidir. Rate limit için kullanılan Redis cache instance'ından farklı criticality taşıyabilir.

Cache Miss Abuse Koruması

Bir client sürekli unique invalid key istiyorsa cache hit oluşmaz. Miss-rate-based limiter bu pattern'i yakalayabilir. Normal user behavior'dan ayrılmalıdır. Negative cache ve Bloom filter limiter ile birlikte çalışabilir. Security telemetry repeated enumeration davranışını kaydeder.

Redis ve CDN Birlikte Nasıl Kullanılır?

CDN internet edge'inde public HTTP response'ları cache'lerken Redis application katmanında daha dinamik veya private data'yı cache'leyebilir. İki katman origin database'e ulaşan request sayısını birlikte azaltır. CDN hit application'a bile gelmez. CDN miss application'a gelir ve Redis hit olabilir. Invalidation zinciri her katmanın TTL ve purge yeteneğine göre tasarlanmalıdır.

CDN Edge Cache

Static ve public cacheable response kullanıcıya yakın noktada tutulur. Network latency ve backend traffic azalır. Cache-Control policy content türüne göre ayarlanır. Personalized response yanlışlıkla public cache'e girmemelidir. Purge API emergency invalidation sağlar.

Redis Application Cache

Application request aldıktan sonra dynamic data Redis'ten okunabilir. Authorization-aware key'ler burada yönetilebilir. CDN ile aynı payload'ı cache'lemek bazen gereksiz olabilir. Redis daha kısa TTL ve daha granular invalidation kullanabilir. Metrics hangi layer'ın hit verdiğini ayrıştırmalıdır.

Database

Hem CDN hem Redis miss olursa origin database'e gidilir. Bu en pahalı path'tir. Cache layers query optimization ihtiyacını ortadan kaldırmaz. Database fallback concurrency korunmalıdır. Cold global cache senaryosu load test edilir.

Public API Responses

Anonymous GET endpoint CDN için iyi aday olabilir. Query parameter canonicalization cache key'i etkiler. Redis backend data fragmentlerini cache'leyebilir. ETag veya conditional requests ayrıca kullanılabilir. User-specific token response public cache'ten ayrılmalıdır.

Cache Invalidation Zinciri

Database update Redis key delete ve CDN purge event'i tetikleyebilir. İki operasyon aynı anda başarısız olabilir. TTL safety net korunur. Event-driven pipeline katmanları bağımsız consumer olarak güncelleyebilir. Freshness SLO en yavaş invalidation layer'a göre değerlendirilmelidir.

Yüksek Trafikli E-Ticarette Redis Kullanımı

E-ticaret sisteminde catalog, pricing, inventory, campaign ve shopping cart aynı freshness politikasına sahip değildir. Redis hepsi için kullanılabilir fakat cache modeli farklı olmalıdır. Product description daha uzun TTL alabilir. Inventory checkout aşamasında authoritative source'tan doğrulanmalıdır. Farklı veri sınıflarını tek büyük product cache object'ine bağlamak gereksiz invalidation ve stale riskini artırır.

Product Catalog

Ürün başlığı, açıklama ve görseller sık okunup seyrek değişebilir. Cache-aside ve uzun TTL uygundur. Search index ayrı data sistemi olabilir. Product update event Redis key'ini silebilir. Viral product hot key için L1 cache değerlendirilebilir.

Pricing

Fiyat kampanya ve kullanıcı segmentine göre değişebilir. Cache key bütün pricing context'i taşımalıdır. Çok yüksek cardinality cache reuse'u azaltabilir. Checkout final fiyat authoritative pricing service üzerinden doğrulanabilir. Price change event kısa sürede cache'i invalidate etmelidir.

Inventory

Stok değeri çok hızlı değişebilir. Display için kısa TTL cache kullanılabilir. Satın alma rezervasyonu cache value'ya güvenmemelidir. Inventory service concurrency-safe decrement veya reservation yapmalıdır. Oversell riskini performans cache'ine bırakmamak gerekir.

Campaign Data

Kampanya configuration yüksek read ve planlı değişim taşır. Cache warming kampanya başlamadan önce yapılabilir. Start time çevresinde TTL expiration yığılmamalıdır. Event-driven activation cache'i yeniler. Campaign end de aynı şekilde invalidate edilmelidir.

Shopping Cart

Cart kullanıcı-specific mutable state'tir ve pure cache olmayabilir. Redis primary cart store olarak kullanılıyorsa persistence ve HA requirement yükselir. Eviction kabul edilebilir değildir. Session ve catalog cache ile aynı policy paylaşmamalıdır. Database veya event persistence recovery planı gerekir.

Farklı Freshness Gereksinimleri

Catalog dakikalar, price saniyeler ve inventory daha kısa süre tolerans gösterebilir. Tek TTL bütün alanları yanlış optimize eder. Data fragment cache farklı key'lerde tutulabilir. Composition application layer'da yapılır. Freshness policy product riskine göre belgelenir.

Mikroservislerde Redis Önbellekleme

Mikroservis mimarisinde cache ownership açık olmazsa bir Redis key'ine birden fazla service bağımlı hale gelebilir. Shared distributed cache teknik olarak mümkün olsa da domain sınırlarını korumak önemlidir. Her service kendi cache schema'sını ve invalidation politikasını sahiplenmelidir. Cross-service değişiklik event üzerinden bildirilebilir. Cache contract doğrudan başka service'in private serialized object'ine bağımlı olmamalıdır.

Shared Distributed Cache

Bir Redis cluster birçok service'e hizmet verebilir. Namespace ve ACL izolasyonu gerekir. Noisy neighbor service diğerlerini etkileyebilir. Capacity attribution service bazında yapılmalıdır. Critical workload gerekirse ayrı deployment almalıdır.

Service-Owned Cache

Her service kendi key formatını ve TTL policy'sini yönetir. Başka service key'i doğrudan okumaz. Data contract API veya event üzerinden kalır. Cache implementation private detail olur. Refactoring cross-service breaking change yaratmaz.

Cross-Service Invalidation

Source service domain change event yayınlar. Consumer service kendi cache key'ini siler. Publisher consumer'ın key formatını bilmez. Event delay eventual consistency oluşturur. TTL lost event safety net olarak kalır.

Event-Driven Invalidation

Message broker birden çok cache consumer'a değişikliği dağıtır. Delete operasyonları idempotent yapılır. Consumer lag izlenir. Replay stale cache'i toplu temizleyebilir. Event schema ve ownership versionlanır.

Cache Ownership

Her cache namespace'in sahibi belli olmalıdır. Owner TTL ve invalidation decision'ından sorumludur. Shared platform yalnızca common library ve infrastructure sunar. Production incident'ta hangi team'in key'i olduğu hızlı bulunur. Governance uncontrolled key growth'u azaltır.

API Response Caching

API response cache endpoint'in nihai payload'ını belirli request identity üzerinden saklar. Bu yöntem backend içindeki birçok database ve service çağrısını tek hit ile atlayabilir. Ancak authorization, pagination ve query parameter semantics key tasarımını hassas hale getirir. User-specific response yanlış shared key'e yazılırsa ciddi veri sızıntısı oluşabilir. Cache poisoning ve stale permission riskleri security review'a dahil edilmelidir.

Endpoint Bazlı Cache

GET endpoint path cache namespace'in bir parçası olabilir. Route version key'e dahil edilir. Mutable POST response genellikle aynı şekilde cache'lenmez. Endpoint owner TTL belirler. Route deprecation key version cleanup ile birlikte yapılır.

Query Parameter Key

Response'u etkileyen parameters canonical sırada key'e eklenir. Default parameter ile omitted parameter aynı logical request'e normalize edilebilir. Unknown parameter key cardinality'yi gereksiz büyütmemelidir. Hash kullanılıyorsa original normalized input debugging için secure trace metadata'da tutulabilir. Cache poisoning input validation ile sınırlandırılır.

User-Specific Response

Response user'a özelse user identity key'e eklenmelidir. Role veya permission response'u değiştiriyorsa authorization version da gerekebilir. Shared public cache namespace kullanılmamalıdır. User deletion cache purge event'i oluşturabilir. Privacy retention TTL ile sınırlanır.

Authorization

Cache hit authorization kontrolünü bypass etmemelidir. Önce user'ın resource'a erişme hakkı doğrulanır veya key permission context'i güvenli biçimde içerir. Permission değişikliği cache'i invalidates etmelidir. Security-sensitive response kısa TTL kullanabilir. Authorization bug cache performansından çok daha ciddi risk taşır.

Pagination

Page veya cursor response'u key'e dahil edilir. Deep pagination çok sayıda düşük-hit key oluşturabilir. First pages daha yüksek reuse taşıyabilir. Cache yalnızca ilk N sayfaya uygulanabilir. Underlying data değişiminde bütün page keys invalidation zorlaşabilir ve version key kullanılabilir.

Cache Poisoning Riskleri

Attacker farklı header veya query input ile yanlış shared response oluşturabilir. Cache key response'u etkileyen bütün güvenli varyantları içermelidir. Host, language veya authorization context gerekiyorsa unutulmamalıdır. Untrusted payload cache'e yazılmadan önce validation almalıdır. Public ve private cache namespace kesin ayrılmalıdır.

Redis Semantic Cache ve AI/LLM Uygulamaları

Semantic cache exact string eşleşmesi yerine anlam olarak benzer prompt veya query'lerin daha önceki güvenli sonuçlarını yeniden kullanmayı amaçlar. Embedding vector similarity üzerinden candidate response bulunabilir. Bu model LLM latency ve token maliyetini azaltabilir. Fakat yanlış semantic hit kullanıcıya ilgisiz veya eski cevap döndürebilir. Tenant, authorization, model version ve knowledge freshness key/filter context'inin parçası olmalıdır.

Exact-Key Cache'den Farkı

Exact cache aynı prompt string için hit verir. Semantic cache farklı kelimelerle aynı niyeti taşıyan sorguları eşleştirebilir. Bu daha yüksek reuse potansiyeli yaratır. Correctness riski de artar. Similarity threshold ve metadata filter bu yüzden kritik hale gelir.

Similar Prompt

“Siparişim nerede?” ile “Kargom ne zaman gelir?” semantic olarak benzer olabilir. Ancak user order context'i farklıdır. Generic FAQ response cache'lenebilirken account-specific answer aynı cache'e girmemelidir. Prompt intent kadar authorization ve entity scope kullanılmalıdır. Human evaluation yanlış hit oranını ölçmelidir.

Embedding

Prompt embedding numeric vector olarak üretilir. Similarity search geçmiş cached query vectors üzerinde yapılır. Embedding model version değişirse vector space değişebilir. Version metadata index'te tutulmalıdır. Model upgrade sırasında eski ve yeni cache birlikte yönetilebilir.

Similarity Threshold

Threshold düşükse daha fazla hit fakat daha fazla yanlış eşleşme olur. Yüksek threshold hit oranını düşürür ancak precision artar. Domain-specific evaluation set tuning için kullanılmalıdır. Tek global threshold bütün intent'ler için doğru olmayabilir. High-risk query semantic cache dışında bırakılabilir.

LLM Latency Azaltma

Cache hit model inference'ı tamamen atlayabilir. Saniyeler süren response milisaniye seviyesine inebilir. Embedding lookup latency yine eklenir. Popular semantic intent'lerde ciddi kullanıcı deneyimi kazancı oluşur. Cache response streaming behavior ayrıca tasarlanmalıdır.

Token Maliyeti Azaltma

Inference çağrısı yapılmadığı için input ve output token maliyeti azalabilir. Embedding üretiminin kendi maliyeti vardır. Exact hash lookup önce uygulanıp semantic search yalnızca miss'te çalıştırılabilir. Cache ROI hit frequency üzerinden ölçülür. Stale knowledge nedeniyle tekrar inference gerektiği zaman policy belirler.

Yanlış Cache Hit Riski

Semantic similarity aynı factual answer garantisi değildir. User-specific context sızıntısı en ciddi risktir. Metadata filters tenant ve permission boundary'yi zorunlu tutmalıdır. Knowledge source version değiştiğinde cache invalidation yapılmalıdır. High-stakes response semantic cache'ten çıkarılabilir.

Redis Kullanırken En Sık Yapılan Hatalar

Redis kullanımı kolay olduğu için ilk implementation çoğu zaman birkaç GET ve SET ile tamamlanır. Production sorunları ise TTL, invalidation, memory ve failure davranışlarında ortaya çıkar. Her şeyi cache'lemek hit oranını yükseltmek yerine memory churn yaratabilir. Stampede ve hot key dikkate alınmadığında yüksek trafikte tek key bütün sistemi zorlayabilir. Cache tasarımı application code, Redis ve origin database'i birlikte kapsamalıdır.

Her Şeyi Cache'lemek

Tekrar okunmayan data cache memory'sini boşa kullanır. Eviction hot value'ları dışarı atabilir. Serialization ve write QPS artar. Cache admission reuse ihtimaline dayanmalıdır. Namespace hit rate düşükse cache kaldırılabilir.

TTL Kullanmamak

Stale value süresiz yaşayabilir. Explicit invalidation hatası permanent hale gelir. Memory cleanup zorlaşır. Version migration eski key'leri bırakabilir. Pure cache için expiration güçlü safety net'tir.

Her Key'e Aynı TTL Vermek

Data freshness requirements farklıdır. Aynı anda populate edilen key'ler birlikte expire olabilir. Avalanche oluşur. Policy veri türü bazında seçilmelidir. Jitter expiration'ı dağıtır.

Stampede Koruması Eklememek

Hot key expiration yüzlerce database call oluşturabilir. Normal testte tek user olduğu için problem görünmez. Load test concurrency'yi ortaya çıkarır. Single-flight ve stale refresh kullanılır. Origin fetch concurrency ayrıca sınırlandırılır.

Cache Invalidation Planı Olmamak

Mutation sonrası stale cache kalır. Developer manuel olarak farklı noktalarda delete ekler. Bazı write path'leri unutulur. Event veya centralized repository pattern standard sağlar. TTL unutulan case'leri sınırlar.

Kötü Key Tasarımı

Eksik tenant veya query parametresi yanlış data paylaşımına yol açar. Non-canonical parameter hit rate'i düşürür. Çok uzun key memory overhead oluşturur. Hash tags hot slot yaratabilir. Key standard code library içinde tutulmalıdır.

Big Key Oluşturmak

Büyük object network ve memory maliyeti yaratır. O(N) operations latency spike oluşturabilir. Collection parçalara ayrılabilir. Projection cache kullanılabilir. Big-key monitoring periyodik çalıştırılmalıdır.

Hot Key'i Görmezden Gelmek

Cluster genel CPU düşükken tek shard saturate olabilir. Node eklemek tek hot key'i dağıtmaz. L1 cache ve replication gerekebilir. Per-key sampling yapılmalıdır. Hotness traffic campaign'lerle değişebilir.

KEYS Kullanmak

Production keyspace büyük olduğunda KEYS uzun blocking work yaratabilir. SCAN incremental alternative'dir. Business logic tarama gerektirmemelidir. ACL runtime user'dan KEYS yetkisini kaldırabilir. Admin tooling bounded scan kullanmalıdır.

Her Request'te Connection Açmak

TCP ve TLS setup latency yaratır. Server client churn yaşar. Connection count hızla büyür. Shared client veya bounded pool kullanılmalıdır. Autoscaling toplam connection budget'ını değiştireceği için hesaplanmalıdır.

Redis Failure'ını Hesaba Katmamak

Her dependency hata verebilir. Cache down olduğunda database fallback overload olabilir. Circuit breaker ve load shedding gerekir. Stale cache bazı veriler için yardımcıdır. Failure testing production öncesi yapılmalıdır.

Cache Hit Rate'i İzlememek

Cache'in gerçekten işe yarayıp yaramadığı bilinmez. Low-hit namespace yıllarca memory tüketebilir. Deployment regression fark edilmez. Hit rate origin offload ile birlikte ölçülmelidir. p99 latency aynı dashboard'da bulunmalıdır.

Session ve Evict Edilebilir Cache'i Karıştırmak

Session data pure cache değildir. Eviction user logout veya state loss yaratabilir. Aynı maxmemory policy iki workload için uygun olmayabilir. Ayrı instance gerekebilir. Criticality sınıflandırması baştan yapılmalıdır.

Production-Ready Redis Cache Checklist

Production-ready cache yalnızca bağlantının çalıştığını doğrulayan bir checklist değildir. Strategy, expiration, resilience, memory, performance ve observability birlikte kontrol edilmelidir. Her veri sınıfının source of truth ve freshness sınırı bilinmelidir. Redis failure'ın database'e ne kadar yük aktaracağı test edilmelidir. Checklist code review, deployment ve kapasite planlama süreçlerinde tekrar kullanılmalıdır.

Cache Strategy

Her namespace hangi cache pattern'ini kullandığını açıkça belirtmelidir. Read-through veya cache-aside seçimi implementation ownership'ini etkiler. Source of truth cache'ten bağımsız tanımlanmalıdır. Mutation path invalidation behavior'ı belgelenmelidir. Strategy gerçek read/write workload'a göre seçilmelidir.

Cache-aside/read-through seçildi mi?

Read path hangi layer'ın origin fetch yaptığını net biçimde tanımlamalıdır. Cache-aside application tarafından, read-through abstraction katmanı tarafından yönetilebilir. İki pattern aynı endpoint içinde kontrolsüz karıştırılmamalıdır. Miss telemetry her durumda bulunmalıdır. Stampede protection pattern seçiminden bağımsız ayrıca eklenmelidir.

Source of truth belli mi?

Cache key kaybolduğunda verinin nereden yeniden üretileceği bilinmelidir. Database veya authoritative service açıkça belirtilmelidir. Redis'e yalnızca başka yerde bulunmayan state yazılıyorsa artık pure cache değildir. Persistence ve HA requirement değişir. Incident runbook bu ayrımı kullanır.

Expiration

Expiration cache freshness ve memory lifecycle'ını yönetir. Her key'in aynı TTL'e sahip olması gerekmez. Jitter toplu expiration riskini azaltır. Stale policy availability ve freshness arasındaki davranışı tanımlar. Business risk yüksek veriler daha kısa veya explicit invalidation odaklı policy kullanmalıdır.

TTL var mı?

Pure cache key'leri makul expiration taşımalıdır. TTL sonsuzsa gerekçe belgelenmelidir. Data değişim sıklığı süreyi belirler. Origin cost çok yüksekse refresh-ahead kullanılabilir. TTL metrics keyspace behavior'ını anlamaya yardımcı olur.

Jitter var mı?

Batch-created key'lerde jitter önerilir. Random range freshness limitini aşmamalıdır. Expiration spike deployment sonrası izlenir. Jitter common cache helper içinde uygulanabilir. Tek hot key stampede'ini tek başına çözmediği unutulmamalıdır.

Stale policy var mı?

Soft TTL veya stale-if-error kullanılacak data sınıfları listelenmelidir. Maximum stale window açık olmalıdır. Critical value'lar stale serving dışında tutulur. Degraded mode UI behavior belirlenir. Hard expiration son sınır olarak korunur.

Resilience

Cache error durumunda application ve origin'in nasıl davranacağı önceden tanımlanmalıdır. Stampede protection normal expiration için önemlidir. Full Redis outage database kapasitesini tehdit edebilir. Fallback rate limit ve circuit ile korunmalıdır. Chaos test bu tasarımı doğrulamalıdır.

Stampede protection var mı?

Hot key için single-flight veya lock uygulanmalıdır. Soft TTL duplicate origin fetch'i azaltabilir. Origin query concurrency ölçülür. Protection failure durumunda database load threshold bulunur. Her key için ağır distributed lock kullanmak gerekmez.

Redis failure fallback var mı?

Cache optional ise fallback origin veya degraded response olabilir. Timeout kısa tutulmalıdır. Critical state için Redis outage application outage olabilir ve HA requirement yükselir. Behavior dependency sınıfına göre değişir. Fallback production load testinde denenmelidir.

Origin korunuyor mu?

Database fallback sınırsız olmamalıdır. Semaphore, token bucket veya load shedding kullanılır. Critical endpoint priority alabilir. Pool saturation alert'i devreye girer. Origin survival cache resilience'ın gerçek başarı kriteridir.

Memory

Memory capacity working set, Redis overhead ve background buffers üzerinden planlanmalıdır. Maxmemory açıkça tanımlanır. Eviction policy workload'a uygun seçilir. Big key ve fragmentation izlenir. Container veya host seviyesinde OS headroom bırakılır.

maxmemory tanımlı mı?

Cache'in kontrollü memory sınırı bulunmalıdır. Limit physical RAM'in tamamı olmamalıdır. Replication ve persistence buffer'larına alan bırakılır. Cluster node'ları ayrı değerlendirilir. Approaching-limit alert eviction öncesi çalışır.

Eviction policy uygun mu?

Hot set pattern LRU veya LFU seçimini etkileyebilir. Session gibi non-evictable state aynı instance'ta olmamalıdır. Volatile policy yalnızca TTL taşıyan keys üzerinde çalışır. Noeviction write errors üretebilir. Policy load testle doğrulanmalıdır.

Performance

Connection reuse, pipeline ve data size cache'in gerçek latency'sini belirler. Big veya hot key Redis server'ın tek bölgesini zorlayabilir. Application serialization ayrıca ölçülmelidir. Cluster kullanılıyorsa cross-slot behavior bilinmelidir. Tuning her zaman end-to-end benchmark ile yapılmalıdır.

Connection pool var mı?

Client connection'ları yeniden kullanmalıdır. Pool veya multiplexing library behavior'ına göre seçilir. Pod count ile toplam connection hesaplanır. Timeout ve reconnect policy belirlenir. Failover reconnect storm test edilir.

Pipelining gerekiyor mu?

Bir request çok sayıda independent Redis command yapıyorsa pipeline değerlendirilebilir. Tek GET için gerekli değildir. Batch size bounded tutulur. Response buffer memory izlenir. Cluster client dispatch davranışı doğrulanır.

Big/hot key kontrol edildi mi?

Top key size ve access frequency periyodik analiz edilmelidir. Big-hot key en riskli kombinasyondur. Local cache veya data partitioning değerlendirilebilir. Shard CPU ve network imbalance izlenir. Key limits developer guideline'da belirtilir.

Observability

Cache'in görünür olması performance tuning ve incident response'u kolaylaştırır. Hit/miss, p99 ve eviction temel metric'lerdir. Origin fetch ve fallback ayrıca izlenir. Trace hit ile miss path'i ayırır. Dashboard namespace ve shard seviyesinde drill-down sağlamalıdır.

Hit/miss izleniyor mu?

Application-level hit ve miss counter bulunmalıdır. Redis keyspace counters destekleyici metric'tir. L1 ve L2 ayrı ölçülür. Negative hit ayrıca sınıflandırılabilir. Trend release regression'ı gösterir.

P99 latency izleniyor mu?

Redis dependency tail latency dashboard'da bulunmalıdır. Node/shard bazında ayrılmalıdır. Network ve command execution karşılaştırılır. Slowlog correlation root cause'u hızlandırır. SLO alert sürdürülen yüksek değerde çalışır.

Eviction alert var mı?

Eviction normal baseline üzerinde hızla artarsa alert verilmelidir. Hit rate ve memory pressure aynı anda gösterilir. New deployment large keys yaratmış olabilir. Capacity veya policy action belirlenir. Thrashing oluşmadan müdahale edilir.

Uçtan Uca Yüksek Trafik Redis Cache Mimarisi Nasıl Kurulur?

Uçtan uca cache mimarisi önce cache edilecek veriyi belirleyip ardından origin cost, key tasarımı, TTL, invalidation ve resilience katmanlarını sırayla kurmalıdır. Cache-aside çoğu ekip için sade başlangıç sağlar. Production'a yaklaştıkça stampede, memory, HA ve observability eklenir. Load test yalnızca sıcak cache'i değil failure ve cold-cache durumlarını da kapsar. Bu yöntem cache'i tek seferlik performans değişikliğinden sürekli yönetilen bir platform yeteneğine dönüştürür.

1. Cache Edilecek Verileri Belirleyin

Sık okunan ve tekrar oranı yüksek data listelenir. Change frequency ve freshness toleransı kaydedilir. Hassas consistency gerektiren state ayrılır. Payload size ölçülür. Cache candidate listesi business owner ile gözden geçirilir.

2. Origin Query Maliyetini Ölçün

Database veya downstream latency baseline alınır. QPS ve CPU impact hesaplanır. Cache miss penalty belirlenir. En pahalı origin call'lar önceliklendirilir. Cache olmadan sistem capacity sınırı bilinir.

3. Cache Key Standardı Oluşturun

Namespace, entity, tenant ve version formatı tanımlanır. Query parameter canonicalization merkezi helper ile yapılır. Sensitive data key'e doğrudan yazılmaz. Cluster hash tag requirement belirlenir. Key length ve collision testleri eklenir.

4. Cache-Aside ile Başlayın

Uygulama önce Redis'i kontrol eder. Miss origin'e gider. Başarılı result TTL ile populate edilir. Redis error request'i gereksiz yere fail ettirmeyebilir. Hit/miss telemetry ilk günden eklenir.

5. Veri Türüne Göre TTL Belirleyin

Catalog, profile ve configuration farklı süre kullanır. Business staleness sınırı temel alınır. Origin cost kararın ikinci girdisidir. Hard ve soft TTL gerektiğinde ayrılır. Policy config ile yönetilebilir.

6. TTL Jitter Ekleyin

Batch-created key expiration'ları zamana dağıtılır. Jitter yüzde veya süre bazlı olabilir. Freshness üst limiti korunur. Expiration histogram izlenir. Avalanche load test ile doğrulanır.

7. Invalidation Stratejisini Kurun

Database mutation sonrası cache delete veya update davranışı seçilir. Event-driven invalidation gerekiyorsa mesaj contract'ı oluşturulur. TTL safety net olarak tutulur. Cache race condition'ları concurrency testine alınır. Source of truth açık kalır.

8. Stampede Protection Ekleyin

Single-flight aynı process duplicate fetch'lerini birleştirir. Çok hot key'lerde distributed lock veya soft TTL eklenir. Lock timeout origin p99 üzerinden belirlenir. Stale serving policy değerlendirilir. Origin concurrent fetch metric'i izlenir.

9. Negative Caching Gereksinimini Değerlendirin

Not-found request oranı ölçülür. Aynı invalid key tekrar ediyorsa negative entry eklenir. TTL kısa tutulur. Create event stale negative cache'i temizler. Abuse varsa rate limiting ve Bloom filter değerlendirilir.

10. Connection Pooling Kurun

Her request yeni connection açmaz. Client library'nin async veya multiplex modeline uygun reuse kurulur. Pool maksimum size tanımlanır. Application replica sayısıyla total connections hesaplanır. Failover reconnect test edilir.

11. Pipelining Gereken Akışları Belirleyin

Bulk independent commands bulunur. Pipeline batch size benchmark edilir. MGET/MSET same-slot alternatifi değerlendirilir. Çok büyük response buffer'dan kaçınılır. Transaction requirement pipeline'dan ayrı çözülür.

12. Memory ve Eviction Policy Ayarlayın

Working set size tahmin edilir. Maxmemory OS headroom bırakarak ayarlanır. LRU veya LFU traffic pattern'e göre seçilir. Noeviction yalnızca uygun state modelinde kullanılır. Eviction spike alert'i eklenir.

13. Hot/Big Key Analizi Yapın

Key size distribution çıkarılır. Per-key request sampling uygulanır. Hot shard CPU kontrol edilir. Big-hot key için local cache veya parçalama yapılır. Application guideline limitleri belgeler.

14. HA Topolojisini Seçin

Tek node capacity yeterliyse Sentinel değerlendirilebilir. Horizontal scaling gerekiyorsa Cluster kullanılır. Replica placement failure domain'lerine dağıtılır. Client topology support doğrulanır. Failover recovery SLO belirlenir.

15. Redis Failure Fallback Ekleyin

Timeout ve circuit breaker ayarlanır. Database fallback concurrency sınırlandırılır. Stale response uygun data için kullanılır. Low-priority request load shed edilebilir. Cache outage chaos testle doğrulanır.

16. Cache Warming Stratejisi Kurun

Hot keys traffic öncesi populate edilir. Warming bütün dataset'i hedeflemez. Origin QPS bounded tutulur. Versioned deployment staged warming kullanır. Warmup success metric release gate olabilir.

17. Monitoring ve Alerting Ekleyin

Hit, miss, p99, memory ve eviction dashboard'a eklenir. Origin QPS ve pool wait aynı yerde görülür. Cluster shard imbalance izlenir. Failover ve replication lag alertleri tanımlanır. Trace cache path'i gösterir.

18. Load Test Yapın

Gerçek key distribution ve payload kullanılır. Read/write oranı production'a benzer tutulur. Hot key ve same-TTL scenarios eklenir. Pipelining ve connection count test edilir. End-to-end p99 ölçülür.

19. Failover/Cold-Cache Testi Yapın

Redis primary durdurulur. Cluster veya Sentinel recovery gözlenir. Cache tamamen boşaltılıp traffic uygulanır. Database survival kontrol edilir. Retry ve circuit davranışı doğrulanır.

20. Gerçek Trafik Verisiyle Sürekli Optimize Edin

Cache workload zaman içinde değişir. Yeni features farklı key pattern üretir. Hit rate düşen namespace yeniden değerlendirilir. Capacity traffic growth ile güncellenir. Yüksek İstekli Ortamlarda Redis ile Önbellekleme yaklaşımının sürdürülebilir olması bu sürekli ölçüm döngüsüne bağlıdır.

Redis İçin En İyi Programlama Dili Hangisidir?

Redis için tek bir en iyi programlama dili yoktur. Network ve cache pattern bilgisi dil seçiminden daha belirleyicidir. Python, JavaScript, TypeScript, Java, Go ve .NET için olgun client seçenekleri bulunur. Client'ın Cluster, Sentinel, TLS, pipelining ve reconnect özellikleri önemlidir. Ekip mevcut backend ekosistemine uygun client'ı seçip production davranışını load test ile doğrulamalıdır.

Python

Python backend ve data uygulamalarında Redis ile sık kullanılır. Async ve sync workload'lar için client davranışı ayrıdır. Serialization CPU yoğun olduğunda Python profiling önemlidir. FastAPI ve Django entegrasyonları common cache wrapper üzerinden standardize edilebilir. Connection reuse ve timeout settings framework default'una bırakılmamalıdır.

redis-py

redis-py Redis'in Python ekosistemindeki temel client seçeneklerinden biridir. Pipeline, Cluster ve çeşitli Redis özelliklerini destekler. Async API kullanılacaksa event loop blocking davranışından kaçınılmalıdır. Connection pool configuration traffic'e göre yapılmalıdır. Client version Redis server upgrade matrix'inde izlenmelidir.

FastAPI/Django

FastAPI async endpoint'lerde async Redis client kullanabilir. Django cache backend abstraction sağlayabilir. Framework cache default key ve TTL behavior'ı incelenmelidir. Business-critical invalidation framework magic'ine bırakılmamalıdır. Application metrics wrapper framework integration'ın üzerinde ortaklaştırılabilir.

JavaScript ve TypeScript

Node.js yüksek I/O concurrency nedeniyle Redis workload'larıyla iyi eşleşebilir. Event loop üzerinde ağır serialization yapılması yine latency yaratabilir. Promise concurrency duplicate cache miss'leri büyütebilir. Single-flight helper özellikle önemlidir. TypeScript cache payload schema'sı için type safety sağlar.

node-redis

node-redis modern Redis features için yaygın JavaScript client seçeneklerinden biridir. Connection reuse ve reconnect configuration incelenmelidir. Cluster usage topology-aware client gerektirir. Pipeline ve multi-command davranışı application benchmark ile doğrulanır. Error event'leri process crash'e yol açmayacak şekilde ele alınmalıdır.

ioredis

ioredis Node.js ekosisteminde Redis ve cluster kullanımında uzun süredir kullanılan client seçeneklerinden biridir. Sentinel ve Cluster topology desteği projeye göre tercih nedeni olabilir. Retry policy default'ları production requirement'a göre gözden geçirilmelidir. Çok agresif retry outage sırasında load oluşturabilir. Kullanılan client güncel maintenance ve Redis version compatibility açısından düzenli review edilmelidir.

Java

Java yüksek concurrency backend sistemlerinde Redis'i farklı client modelleriyle kullanabilir. Blocking ve asynchronous access arasında seçim yapılabilir. Connection pool yalnızca kullanılan client mimarisine göre ayarlanmalıdır. Spring abstraction hızlı entegrasyon sağlarken Redis-specific performance details gözden kaçmamalıdır. JVM serialization ve GC payload size ile birlikte ölçülmelidir.

Jedis

Jedis Redis için yaygın Java client seçeneklerinden biridir. Connection kullanımı ve pooling version'a göre doğru yapılandırılmalıdır. Cluster API ayrı topology davranışı taşır. Pipeline bulk operation'larda faydalı olabilir. Client timeout ve failover tests production öncesi yapılmalıdır.

Lettuce

Lettuce asynchronous ve reactive kullanım modelleriyle yüksek concurrency sistemlerinde tercih edilebilir. Netty tabanlı network modeli connection multiplexing imkanı sağlar. Her request için çok connection açmak gerekmez. Cluster topology refresh ayarları önemlidir. Event loop üzerinde blocking application işi yapılmamalıdır.

Spring Cache

Spring Cache application code'una annotation tabanlı abstraction sunabilir. Basit method result caching hızla uygulanabilir. Key generation ve invalidation semantics bilinmeden annotation eklemek risklidir. Stampede protection default olarak garanti edilmez. Production telemetry framework abstraction'ın altında Redis behavior'ını göstermelidir.

Go

Go düşük overhead concurrency modeliyle Redis kullanan backend servisleri için uygundur. Context deadline dependency timeout'larını yönetir. Goroutine sayısı sınırsız origin fallback concurrency anlamına gelmemelidir. Redis client connection pool behavior'ı anlaşılmalıdır. Binary serialization ve JSON tercihleri CPU profiliyle karşılaştırılabilir.

go-redis

go-redis Go ekosisteminde yaygın Redis client seçeneklerinden biridir. Cluster, Sentinel ve pipeline kullanım senaryoları bulunur. Context timeout her command'a taşınabilir. Pool stats observability sistemine eklenebilir. Failover ve retry configuration chaos testle doğrulanmalıdır.

C#/.NET

.NET servisleri Redis'i async API ile yüksek concurrency altında kullanabilir. Connection object'in her request için yeniden oluşturulmaması önemlidir. Serializer allocation ve GC etkisi izlenmelidir. Distributed cache abstraction application portability sağlar. Redis-specific advanced features gerektiğinde daha doğrudan client API kullanılabilir.

StackExchange.Redis

StackExchange.Redis .NET dünyasında yaygın kullanılan Redis client'larından biridir. ConnectionMultiplexer uzun ömürlü olarak reuse edilmek üzere tasarlanır. Her request için yeni multiplexer açmak ciddi performans kaybı yaratabilir. Async API thread blocking riskini azaltır. Reconnect ve topology event'leri monitoring sistemine bağlanabilir.

Programlama Dilinden Daha Önemli Olan Cache ve Dağıtık Sistem Bilgisi

Yanlış TTL kullanan en hızlı dil yine database avalanche yaratabilir. Hot key'i anlamayan implementation Cluster kapasitesini kullanamaz. Distributed lock hataları programlama dilinden bağımsızdır. Cache invalidation ve failure recovery temel mimari bilgisidir. Bu nedenle geliştiricinin Redis command ezberinden önce distributed systems davranışını öğrenmesi daha değerlidir.

Redis Alanında Yazılımcı Olmak İçin Ne Öğrenilmeli?

Redis geliştirme yalnızca GET ve SET command'larını bilmek değildir. Network latency, database access, cache semantics ve concurrency temelini anlamak gerekir. Replication ve Cluster failure davranışı production sistemlerinde belirleyicidir. Observability ve load testing sorun ortaya çıkmadan kapasite sınırlarını gösterir. Öğrenme yolu küçük uygulamadan başlayıp failure ve scale senaryolarını deneyerek ilerlemelidir.

Networking

TCP connection, RTT ve timeout kavramları Redis latency'sini anlamanın temelidir. Pipelining neden hızlandırır sorusu network bilgisiyle açıklanır. TLS handshake connection reuse ihtiyacını gösterir. Cross-region latency in-memory avantajını azaltabilir. Packet loss retry davranışını etkiler.

Database Temelleri

Cache hangi origin işini azaltıyor bilinmelidir. Index, query plan ve connection pool kavramları anlaşılmalıdır. Cache kötü database query'yi yalnızca gizleyebilir. Source of truth ve transaction semantics consistency için önemlidir. Database failure cache stratejisini etkiler.

Caching

Hit, miss, TTL ve invalidation temel konulardır. Cache-aside ve write pattern'leri öğrenilmelidir. Stampede ve avalanche high traffic behavior'ını açıklar. Negative caching penetration sorununu çözer. Cache effectiveness metric'leri gerçek faydayı ölçer.

Concurrency

Aynı key'e paralel request geldiğinde race condition oluşabilir. Single-flight ve lock concurrency araçlarıdır. Atomic Redis commands belirli state updates için faydalıdır. Idempotency lock'tan ayrı kavramdır. Concurrent tests sadece unit testle sınırlı kalmamalıdır.

Distributed Systems

Network partition ve partial failure normal olaylardır. Replica lag eventual consistency yaratır. Failover client topology'sini değiştirir. Retry doğru sınırlandırılmazsa storm oluşturur. Distributed cache tasarımı bu gerçeklere dayanmalıdır.

Redis Data Types

String dışında hash, set, sorted set ve stream gibi yapılar öğrenilmelidir. Her type'ın command complexity'si farklıdır. Big collection riskleri anlaşılmalıdır. Data model command access pattern'e göre seçilir. Her şeyi tek JSON string yapmak her zaman optimal değildir.

TTL ve Eviction

Expiration freshness sağlar. Jitter avalanche'ı azaltır. Maxmemory ve policy capacity behavior'ını belirler. LRU ve LFU workload'a göre farklı sonuç üretir. Eviction ile expiration metric'leri birbirinden ayrılmalıdır.

Replication

Primary-replica data flow ve lag bilinmelidir. Failover sırasında son writes tamamen garanti altında olmayabilir. Replica reads stale olabilir. Cache ve durable state bu riski farklı değerlendirir. Monitoring replication health'i sürekli takip eder.

Cluster

Hash slots ve key tags öğrenilmelidir. Multi-key operation same-slot restriction taşır. Resharding topology change oluşturur. Hot key horizontal scale'i sınırlayabilir. Cluster-aware client behavior test edilmelidir.

Observability

Hit rate, p99, memory ve eviction temel metric'lerdir. SLOWLOG server-side hotspot gösterir. Application trace network ve serialization süresini ekler. Alert threshold baseline üzerinden belirlenir. Dashboard root cause analizini hızlandırır.

Load Testing

Synthetic ops/sec tek başına yeterli değildir. Realistic key distribution kullanılır. Cold cache ve failure scenarios eklenir. Database fallback survival ölçülür. Performance bilgisi ancak ölçülen sistem behavior'ıyla kalıcı hale gelir.

Open Source ve İşbirliği ile Redis

Redis ekosistemi server, client library, monitoring ve çeşitli veri işleme araçları etrafında geniş bir geliştirici topluluğuna sahiptir. Redis 8 ve sonrasında Redis Open Source, AGPLv3 seçeneğini de içeren lisans yapısıyla sunulmaktadır. Client library katkıları application geliştiricileri için önemli bir katmandır. Benchmark ve cache middleware projeleri topluluk içinde birlikte geliştirilebilir. Açık kaynak katkısı Redis internals öğrenmenin yanında gerçek production sorunlarını daha iyi anlamaya da yardımcı olur.

Redis Açık Kaynak Ekosistemi

Redis server code ve ekosistemdeki çeşitli client projeleri geliştiricilere inceleme ve katkı imkanı sunar. Redis 8 ile JSON, time-series ve probabilistic data gibi daha önce ayrı sunulan bazı yetenekler Redis Open Source dağıtımında bir araya getirilmiştir. Lisans seçimi kurumun kullanım ve dağıtım modeline göre hukuk ekibiyle değerlendirilmelidir. Teknik öğrenme açısından issue ve pull request geçmişi önemli kaynak sağlar. Production uygulaması yalnızca yeni özelliklere değil stability ve compatibility gereksinimlerine göre sürüm seçmelidir.

Client Library'ler

Client library Redis protocol detaylarını application için kullanılabilir API'ye dönüştürür. Cluster routing, Sentinel discovery ve pipelining gibi özellikler library kalitesine bağlıdır. Community issue'ları gerçek edge case'leri gösterir. Kullanılan client aktif bakım ve security açısından izlenmelidir. Upstream contribution bug fix'in yalnızca kurum içinde fork olarak kalmasını engelleyebilir.

Redis Insight

Redis Insight geliştirme ve operasyon sırasında Redis data ve sorgularını görselleştirmeye yardımcı olan araçlardan biridir. Production access kontrollü ve read permission ağırlıklı olmalıdır. Big key veya query investigation sırasında destek sağlayabilir. GUI monitoring sisteminin yerine geçmez. Ekip eğitimlerinde Redis data type davranışını göstermek için faydalı olabilir.

Benchmark Araçları

Benchmark tooling command throughput ve latency baseline üretir. Synthetic sonuç gerçek application workload ile doğrulanmalıdır. Custom scripts hot key ve payload distribution'ını daha gerçekçi modelleyebilir. Open source load generator'lara yeni scenario katkısı yapılabilir. Result methodology repository içinde paylaşılırsa ekipler aynı testleri tekrar çalıştırabilir.

GitHub Üzerinden Katkı

Bug report iyi reproduction ve version bilgisi içermelidir. Documentation fix de değerli açık kaynak katkısıdır. Client library edge case'i için test eklemek öğrenme açısından faydalıdır. Upstream contribution kurum içi patch bakımını azaltabilir. Contribution guideline ve lisans koşulları takip edilmelidir.

Cache Pattern Kütüphaneleri

TTL jitter, single-flight ve key standardı ortak library içinde uygulanabilir. Her ekip aynı hataları tekrar çözmez. Library framework'e aşırı bağlı olmamalıdır. Metrics ve tracing default olarak bulunmalıdır. Open source paylaşım generic ve güvenli pattern'leri toplulukla geliştirmeye imkan verir.

Ortak Performance Test Projeleri

Farklı dillerde Redis client behavior'ı aynı benchmark senaryosuyla karşılaştırılabilir. Pipelining ve hot key testleri birlikte geliştirilebilir. Sonuçlar hardware ve network bilgisiyle yayınlanmalıdır. Tek sayı yerine methodology paylaşmak daha öğreticidir. Diyarbakır Yazılım Topluluğu'nun proje yaklaşımını incelemek için https://www.diyarbakiryazilim.com.tr/projects adresi kullanılabilir.

Diyarbakır Yazılım Topluluğu İçin Redis Proje Fikirleri

Redis'i öğrenmenin en etkili yollarından biri kontrollü failure ve traffic senaryolarını gerçek uygulamada oluşturmaktır. Basit CRUD demo yerine cache hit, stampede, failover ve hot key davranışlarını ölçen projeler daha öğreticidir. Backend, DevOps ve observability ekipleri aynı çalışma üzerinde işbirliği yapabilir. Her proje önce baseline sonra optimizasyon sonucu raporlayabilir. Böylece yalnızca Redis command bilgisi değil production düşünme biçimi de gelişir.

Yüksek Trafikli API Cache Lab

Basit product API önce doğrudan database ile çalıştırılabilir. Ardından cache-aside Redis eklenir. Hit rate ve origin QPS karşılaştırılır. Load generator p95 ve p99 ölçer. Son aşamada Redis kapatılarak fallback survival test edilir.

Redis Stampede Prevention Workshop

Tek hot key kısa TTL ile oluşturulur. Yüzlerce concurrent request expiration anında gönderilir. İlk test database stampede'i gösterir. Single-flight ve soft TTL sırayla eklenir. Origin QPS farkı grafikle karşılaştırılır.

Redis Cluster Atölyesi

Birden fazla primary ve replica ile küçük Cluster kurulur. Hash slot ve MOVED response davranışı incelenir. Hash tag ile same-slot MGET denenir. Bir primary kapatılarak failover gözlenir. Resharding sırasında client behavior ölçülür.

Hot-Key Detection Projesi

Zipf traffic distribution üreten load generator hazırlanır. Shard CPU ve per-key sampling toplanır. Hot key L1 cache eklenmeden önce ve sonra test edilir. Network QPS farkı ölçülür. Dashboard hangi key'in bottleneck olduğunu gösterir.

Cache Observability Dashboard

Hit, miss, p99, memory ve eviction metric'leri tek dashboard'da toplanır. Origin database QPS aynı grafiğe eklenir. Redis failover event annotation olarak gösterilir. Namespace bazlı cache efficiency raporu hazırlanır. Alert rules workshop sonunda chaos test ile doğrulanır.

Redis Load Testing Hackathon'u

Takımlar farklı client library ve pipeline strategy deneyebilir. Aynı hardware ve workload specification kullanılır. Sadece ops/sec değil p99 ve memory ölçülür. Hot key ve cold-cache turu eklenir. Sonuçlar methodology ile birlikte karşılaştırılır.

Açık Kaynak Cache Middleware Projesi

Middleware key versioning, TTL jitter ve single-flight özelliklerini ortak sunabilir. OpenTelemetry metric ve trace default gelir. Redis failure circuit breaker entegrasyonu eklenir. Birden fazla dilde reference implementation üretilebilir. Topluluk hakkında daha fazla bilgi için https://www.diyarbakiryazilim.com.tr/about adresi incelenebilir.

Sık Sorulan Sorular

Redis cache konusunda en sık sorulan sorular doğru TTL, cache pattern, Cluster ve failure davranışı çevresinde toplanır. Tek bir configuration bütün workload'lar için doğru değildir. Cache değerinin ne kadar sık değiştiği ve origin maliyeti kararın temelini oluşturur. Production sistemlerde hit rate kadar stampede, memory ve p99 latency de izlenmelidir. Aşağıdaki cevaplar en sık karşılaşılan teknik kararları pratik biçimde özetler.

Redis cache nedir?

Redis cache sık kullanılan verinin memory ağırlıklı hızlı bir katmanda geçici kopyasını saklamaktır. Application önce Redis'e bakabilir. Hit durumunda database query atlanır. Miss durumunda origin'den veri alınır ve cache'e yazılır. Source of truth çoğu cache-aside sistemde database olarak kalır.

Redis yüksek trafikte neden kullanılır?

Redis tekrar eden read request'lerini düşük latency ile karşılayabilir. Database connection ve CPU yükünü azaltır. Traffic spike sırasında origin'i koruyan buffer görevi görebilir. Distributed application instances ortak cache kullanır. Stampede ve failure koruması olmadan bu avantaj production'da yeterli değildir.

Cache-aside nedir?

Application önce cache'i kontrol eder. Value yoksa database'e gider. Sonucu Redis'e TTL ile yazar. Mutation sonrasında key çoğunlukla silinir. Basit ve read-heavy sistemlerde yaygın kullanılan bir pattern'dir.

Redis TTL kaç olmalıdır?

Tek doğru TTL yoktur. Veri değişim sıklığı ve kabul edilen staleness temel girdidir. Origin query maliyeti ve trafik yoğunluğu da süreyi etkiler. Hot key için soft TTL ve refresh-ahead kullanılabilir. Jitter toplu expiration riskini azaltır.

Cache stampede nedir?

Popüler key cache'ten kaybolduğunda çok sayıda request aynı anda origin'e gider. Database aynı veriyi tekrar tekrar üretir. Connection pool saturation oluşabilir. Single-flight veya distributed lock duplicate fetch'i azaltır. Soft TTL kullanıcıya stale value sunarak origin refresh'i tek worker'a bırakabilir.

Cache avalanche nedir?

Çok sayıda key kısa sürede cache'ten kaybolur. Aynı TTL veya Redis restart sık nedenlerdir. Origin ani büyük traffic alır. TTL jitter ve staged warming riski azaltır. Rate limit ve load shedding database'i korur.

Cache penetration nedir?

Olmayan resource'lara sürekli request geldiğinde her seferinde cache ve database miss oluşur. Random ID abuse tipik örnektir. Negative caching aynı invalid key'i durdurur. Bloom filter büyük valid-set için erken eleme sağlar. Input validation ve rate limiting güvenlik katmanını tamamlar.

Hot key nedir?

Toplam Redis traffic'inin büyük bölümünü alan tek veya az sayıda key hot key olarak adlandırılır. Cluster'da bu key tek shard'a düşer. Shard CPU veya network saturation yaşayabilir. L1 cache ve key replication yardımcı olabilir. Per-key telemetry problemi erken bulmalıdır.

Big key nedir?

Normal dataset'e göre çok büyük value veya collection taşıyan key big key'dir. Büyük payload network ve serialization maliyeti yaratır. O(N) commands latency spike oluşturabilir. Delete veya expire işlemi pahalı olabilir. Big ve hot key aynı şey değildir.

Redis LRU ile LFU arasındaki fark nedir?

LRU yakın zamanda kullanılmayan key'leri çıkarmaya odaklanır. LFU daha seyrek kullanılan key'leri seçmeye çalışır. Temporal locality güçlü workload LRU'dan faydalanabilir. Stable popularity dağılımı LFU için uygun olabilir. Gerçek hit rate ve eviction metric'i seçim için kullanılmalıdır.

Redis Cluster ne zaman kullanılmalıdır?

Dataset veya throughput tek primary kapasitesini aştığında Cluster değerlendirilir. Keyspace 16.384 slot üzerinden primary node'lara dağıtılır. Replicas failover sağlar. Multi-key operations same-slot kısıtlarını dikkate almalıdır. Sadece HA gerekiyor ve dataset tek node'a sığıyorsa Sentinel daha sade olabilir.

Redis Sentinel ile Cluster arasındaki fark nedir?

Sentinel non-clustered Redis için monitoring ve automatic failover sağlar. Dataset'i birden fazla primary arasında shard etmez. Redis Cluster horizontal sharding ile birlikte failover yeteneği sunar. Cluster client topology awareness gerektirir. Seçim capacity ve operasyon gereksinimine göre yapılır.

Redis cache çökerse uygulama çalışmaya devam eder mi?

Pure cache ise uygulama teorik olarak origin üzerinden çalışabilir. Ancak bütün traffic database'e dönerse origin çökebilir. Controlled fallback ve load shedding gerekir. Stale value uygun data için kullanılabilir. Session veya critical state Redis'te tutuluyorsa cache artık optional dependency değildir.

Redis'te cache invalidation nasıl yapılır?

TTL basit safety net sağlar. Database mutation sonrası explicit delete uygulanabilir. Event-driven invalidation microservice cache'lerini güncelleyebilir. Versioned key büyük schema change için kullanılabilir. Critical data birden fazla yöntemi birlikte kullanabilir.

Redis pipelining nedir?

Pipelining birçok independent command'ı response beklemeden batch halinde göndermeye yarar. Network RTT maliyeti azalır. Throughput yükselir. Çok büyük batch response memory'sini artırabilir. Transaction garantisi pipeline'ın doğal özelliği değildir.

Redis connection pooling gerekli midir?

Connection reuse kesinlikle önemlidir. Ancak klasik pool gereksinimi client library'nin multiplexing ve async modeline bağlıdır. Her request için yeni connection açılmamalıdır. Total connection sayısı application replica count ile hesaplanmalıdır. Timeout ve reconnect policy production testinden geçmelidir.

Redis için Python mı Node.js mi kullanılmalıdır?

İki dil de Redis için güçlü client ekosistemine sahiptir. Seçim mevcut backend mimarisi ve ekip deneyimine göre yapılmalıdır. Node.js I/O concurrency, Python ise geniş backend ve data ecosystem avantajı sunar. Redis performance'ın büyük kısmı doğru cache design ve network behavior'dan gelir. Client library Cluster, Sentinel ve async requirement'ları karşılamalıdır.

Redis'te yüksek trafik nasıl test edilir?

Production'a benzer key distribution ve payload kullanılmalıdır. Concurrent clients ve real read/write ratio modellenir. Hot key ve TTL expiration senaryoları eklenir. Redis failure ve cold cache ayrıca test edilir. Sonuç Redis ops/sec yanında application p99 ve database survival üzerinden değerlendirilir.

Yüksek istek alan uygulamalarda Redis ile önbellekleme nasıl yapılandırılmalıdır?

Yüksek istek alan uygulamada önce sık tekrarlanan ve origin maliyeti yüksek veriler seçilmelidir. Cache key standardı, veri türüne özgü TTL ve jitter başlangıçtan tanımlanmalıdır. Cache-aside read-heavy uygulamalar için sade başlangıç sağlar ve popüler key'lerde single-flight veya soft TTL eklenir. Memory limiti, eviction policy, connection reuse ve failover topology production trafik seviyesine göre boyutlandırılmalıdır. Yüksek İstekli Ortamlarda Redis ile Önbellekleme tasarımının gerçek başarısı hit rate, p99 latency ve origin QPS azalması birlikte ölçüldüğünde anlaşılır.

Redis cache-aside ve write-through stratejilerinden hangisi yüksek trafikli sistemlerde tercih edilmelidir?

Read-heavy ve source-of-truth database olan sistemlerde cache-aside genellikle daha sade başlangıçtır. Mutation sonrasında key silinir ve sonraki read fresh value'yu yeniden populate eder. Write-through read-after-write cache freshness'ını artırır fakat database ile Redis arasında dual-write failure senaryosu ekler. Çok sık read-after-write gerektiren veri sınıflarında write-through faydalı olabilir. Seçim bütün uygulama için değil veri türünün read/write oranı ve consistency gereksinimine göre yapılmalıdır.

Cache stampede ve hot key problemleri Redis üzerinde nasıl önlenir?

Stampede için aynı key'in duplicate origin fetch'leri single-flight ile birleştirilebilir. Multi-instance coordination gerekiyorsa kısa ömürlü owner-token kullanan Redis lock değerlendirilebilir. Soft TTL ve refresh-ahead kullanıcıya eski değeri geçici sunarken tek worker'ın cache'i yenilemesine imkan verir. Hot key normal hit trafiğinde Redis shard'ını zorladığında L1 local cache veya server-assisted client-side caching Redis QPS'ini azaltabilir. Redis cache stampede TTL eviction ve distributed locking nasıl yönetilir sorusunun özü, origin ve tek shard üzerinde eşzamanlı yükü sınırlamaktır.

Redis önbelleklemede TTL, eviction policy, clustering ve veri tutarlılığı nasıl yönetilmelidir?

TTL business freshness sınırından türetilmeli ve key'lerin toplu expire olmaması için jitter uygulanmalıdır. Eviction policy access distribution'a göre LRU veya LFU gibi seçeneklerden seçilmeli, sürekli eviction oluşuyorsa working set ve maxmemory yeniden değerlendirilmelidir. Dataset veya throughput tek node kapasitesini aşıyorsa Redis Cluster, yalnızca non-clustered HA ihtiyacında ise Sentinel değerlendirilebilir. Veri tutarlılığı için source of truth açık tutulmalı ve database mutation sonrasında delete, update veya event-driven invalidation kullanılmalıdır. TTL explicit invalidation'ın yerine değil, kaçırılan durumlar için güvenlik ağı olarak düşünülmelidir.

Yüksek trafikli sistemlerde Redis önbellekleme ve performans optimizasyonu konusunda yakınımda danışmanlık veya eğitim nerede bulabilirim?

Redis performans ve backend danışmanlığı yakınımda şeklinde araştırma yaparken yalnızca Redis kurulumu değil cache pattern, database offload, stampede, observability ve failover konularını birlikte değerlendirebilen bir yaklaşım aramak faydalıdır. Diyarbakır Yazılım Topluluğu'nun yapısı hakkında https://www.diyarbakiryazilim.com.tr/about adresinden bilgi alınabilir. Ölçeklenebilir veritabanı mimarilerinin cache tasarımıyla ilişkisini incelemek için https://www.diyarbakiryazilim.com.tr/posts/veritabani-mimarisinde-olceklenebilirlik-sharding-ve-replication adresindeki içerikten yararlanılabilir. Kurumsal Redis cache performans optimizasyonu ve entegrasyon hizmeti değerlendirilirken gerçek production workload'u üzerinden benchmark ve failure testlerinin kapsamda olması önemlidir. Eğitim çalışmalarında ise stampede, hot key, failover ve cold-cache senaryolarını uygulamalı olarak görmek teorik Redis bilgisini production deneyimine dönüştürür.

Sonuç: Redis Cache Mimarisi Yüksek Trafikte Nasıl Sürdürülebilir Hale Getirilir?

İyi bir Redis cache mimarisi en yüksek hit oranını kovalamak yerine kullanıcı latency'si, origin tasarrufu, freshness ve failure dayanıklılığı arasında ölçülebilir denge kurar. Yüksek İstekli Ortamlarda Redis ile Önbellekleme cache-aside ile başlayabilir, ancak trafik büyüdükçe TTL jitter, stampede protection, hot-key kontrolü, memory yönetimi, HA ve gözlemlenebilirlik zorunlu hale gelir. Redis'in hızlı olması kötü key tasarımı, sınırsız connection, yanlış eviction veya uncontrolled database fallback sorunlarını kendiliğinden çözmez. Cache'in gerçek başarısı Redis çöktüğünde bile kritik sistemlerin kontrollü biçimde çalışmaya devam edebilmesi ve normal zamanda database yükünün anlamlı biçimde azalmasıyla ölçülür. Redis, backend performansı ve ölçeklenebilir uygulama projeleri üzerine Diyarbakır Yazılım Topluluğu çalışmalarını incelemek için https://www.diyarbakiryazilim.com.tr/projects adresini ziyaret edebilirsiniz.