“Daha iyi performans” için L1, L2 ve L3 cache ekledik. Artık verinin yanlış olabileceği 1 yerine 3 yerimiz var.

Muhteşem mimarimiz:

  • L1: Süreç içi cache (Guava)
  • L2: Yerel Redis
  • L3: Dağıtık Redis cluster'ı
  • Gerçek kaynak: PostgreSQL

Ne ters gitti:

  • L3 cache doğru şekilde geçersiz kılındı
  • L2 cache'te hâlâ eski veri vardı (farklı TTL)
  • A sunucusundaki L1 cache'te eski veri vardı
  • B sunucusundaki L1 cache'te yeni veri vardı
  • Kullanıcılar her yenilemede farklı veri gördü

Debugging cehennemi:

“Hatalı veri hangi cache katmanında?” sorusu her seferinde 2 saatlik bir soruşturmaya dönüştü.

Öğrendiklerimiz:

  • Her cache katmanı invalidation karmaşıklığını katlar
  • TTL'ler koordine edilmeli (iç cache < dış cache)
  • Her katmana gözlemlenebilirlik gerekir
  • Bazen tek cache yeterlidir

Ders: Daha fazla cache katmanı ≠ daha iyi performans. İşler ters gittiğinde debug edilecek daha fazla yer demektir. Bir katman daha eklemeden önce izleme ve gözlemlenebilirlik yığınınızın hâlihazırda sahip olduklarınızın içini görebildiğinden emin olun.

← Çıkarılan Dersler'e dön

Bu tür olaylar önlenebilir. AWS Yönetilen Hizmetler ekibimiz müşteri ortamlarını yapay zekâ destekli izleme ve nöbetteki kıdemli mühendislerle 7/24 gözetir — böylece bu tür hikâyeler arşivde kalır.

Etiketler: #Önbellekleme #Mimari #Performans #Debugging