Tutarlılık Sorununu Katmanına Ayırın

Cache ve read replica gecikmeyi azaltır; ancak yazma sonrasında eski verinin görünmesi, silinen kaydın cache’ten dönmesi veya aynı kullanıcının farklı isteklerde farklı sonuçlar alması gibi sorunlar doğurabilir. Önce problemin hangi katmanda oluştuğunu belirleyin:

• Yazma primary’de tamamlandıktan sonra replica gecikiyor mu?
• Cache anahtarı süresi dolmadığı için eski değer mi dönüyor?
• Okuma isteği beklenmedik biçimde replica’ya mı yönleniyor?
• Birden fazla servis aynı kaydı farklı TTL veya invalidation politikalarıyla mı yönetiyor?
• Silme, yeniden adlandırma ya da yetki değişikliği gibi işlemler tüm cache katmanlarına ulaşıyor mu?

Her istekte en azından istek kimliği, kullanıcı veya oturum bağlamı, yazma zamanı, okuma zamanı, seçilen veri kaynağı ve dönen kaydın sürümü izlenmelidir. Ortalama gecikme tek başına yeterli değildir; p95 ve p99 değerleriyle birlikte eski veri görülme oranı da ölçülmelidir.

Okuma-Yazma Garantisini Tanımlayın

“Tutarlı” ifadesi iş kuralına çevrilmeden doğru mimari seçilemez. Kullanıcı kendi profil güncellemesini hemen görmeli olabilir; buna karşılık raporlama ekranında birkaç saniyelik gecikme kabul edilebilir. Her veri türü için şu sorular yanıtlanmalıdır:

• Yazma sonrasında aynı oturumun kendi yazdığı veriyi görmesi zorunlu mu?
• Silme veya yetki değişikliği ne kadar süre gecikmeli olabilir?
• Farklı kullanıcıların aynı kaydı farklı sürümlerde görmesi kabul edilebilir mi?
• Tutarlılık garantisi bozulduğunda istek başarısız mı olmalı, yoksa kullanıcıya durum mu bildirilmelidir?

Kritik yazmalardan sonra kısa süreli primary okuması, oturum bazlı yönlendirme veya minimum sürüm kontrolü uygulanabilir. Her isteği primary’ye göndermek basit bir çözümdür; ancak bağlantı havuzu, CPU, gecikme ve maliyet ölçülmeden kalıcı çözüm olarak kabul edilmemelidir.

Cache Stratejisini Veri Türüne Göre Seçin

• Cache-aside: Okuma önce cache’i kontrol eder, eksikse kalıcı veri kaynağına gider. Yazma sonrası invalidation açıkça yönetilmelidir.
• Write-through: Cache güncellemesi kalıcı yazmayla birlikte yürütülür. Kısmi başarısızlık ve yeniden deneme davranışı tasarlanmalıdır.
• Kısa TTL: Tutarsızlık penceresini daraltır; fakat eski veriyi tamamen engellemez.
• Sürüm kontrollü değer: Daha eski bir yanıtın yeni değerin üzerine yazılmasını önlemeye yardımcı olur.

Cache silme işlemi ayrı bir mesajlaşma akışına bırakılıyorsa outbox veya güvenilir bir queue değerlendirilebilir. Mesajların tekrarlanabileceği, sırasının değişebileceği ve gecikebileceği varsayılmalıdır. Invalidation işlemi idempotent olmalı; mesajın kaç kez işlendiği değil, son geçerli sürümün ne olduğu belirleyici olmalıdır. Bu yaklaşım gecikmeli tutarlılık sunduğundan iş kuralıyla uyumu ayrıca doğrulanmalıdır.

Veri Bütünlüğünü Veritabanında Koruyun

Cache veya replica kaynaklı bir hata, kalıcı olarak geçersiz veri üretememelidir. Benzersiz kayıtlar için UNIQUE kısıtları, ilişkiler için foreign key’ler ve izin verilen durum geçişleri için veritabanı kısıtları kullanılmalıdır. Transaction sınırları da açıkça belirlenmeli; birbirine bağlı yazmaların yalnızca bir bölümünün başarılı kalması engellenmelidir.

Eşzamanlı güncellemelerde sürüm alanı veya zaman damgası kullanılabilir. Kavramsal akış şöyledir:



Etkilenen kayıt sayısı beklenenden farklıysa işlem sessizce başarılı sayılmamalıdır. Kontrollü retry kullanılabilir; ancak deneme sayısı sınırlı olmalı, işlemler idempotent tasarlanmalı ve dış sistemlere gönderilen yan etkiler transaction’dan ayrı güvenilir bir mekanizmayla ele alınmalıdır.

Ölçümleme, İzleme ve Alarm

Aşağıdaki metrikleri veri türü, endpoint ve kaynak bazında ayırmak daha anlamlı sonuç verir:

• Cache hit/miss oranı ve anahtar bazında invalidation başarısızlıkları
• Replica gecikmesi, primary-replica sürüm farkı ve gecikmenin p95/p99 değerleri
• Yazma sonrası belirli süre içinde eski veri gören istek oranı
• Queue bekleme süresi, yeniden deneme sayısı ve başarısız mesajlar
• Optimistic locking çatışmaları ve retry oranı
• Primary’ye yönlendirilen okuma yüzdesi
• Tutarlılık doğrulaması yapılan isteklerin p50, p95 ve p99 gecikmeleri

Alarm tek bir eşik üzerinden kurulmamamalıdır. Replica gecikmesi yükselirken eski veri oranı da artıyorsa geçici primary okuması düşünülebilir. Böyle bir fallback; bağlantı havuzu, rate limit, circuit breaker ve geri dönüş koşullarıyla birlikte test edilmelidir. Aksi durumda tutarlılık sorununu azaltırken primary üzerinde zincirleme yük oluşturabilir.

Yayın Öncesi Hata Senaryoları

Yazma tamamlandıktan hemen sonra okuma, cache silme servisinin durması, replica gecikmesinin artması, aynı kayda eşzamanlı güncelleme, queue mesajının tekrarlanması ve mesaj sırasının değişmesi ayrı test edilmelidir. Her testte şu bilgiler kaydedilmelidir:

• Kullanıcı hangi sürümü gördü?
• İstek hangi kaynaktan yanıtlandı?
• Eski veri ne kadar süre görünür kaldı?
• Kalıcı veri kaynağındaki son durum neydi?
• Sistem çatışmayı veya gecikmeyi nasıl toparladı?

Önce kabul edilebilir tutarlılık penceresini ve başarısızlık davranışını tanımlayın; ardından cache politikası, replica yönlendirmesi, transaction sınırları, veritabanı kısıtları ve ölçümlemeyi birlikte tasarlayın. Performans kazanımı, veri bütünlüğü garantisinin yerine geçmez.