İşleri hızlandırmak için bir Redis cache ekledik. Her isteği yavaşlattı.

Neyi cache'ledik:

  • Kullanıcı profilleri (her istekte okunuyordu ama o kadar sık güncelleniyordu ki kayıtlar neredeyse anında bayatlıyordu)
  • Alışveriş sepeti (kullanıcıya özel, uçucu)
  • Gerçek zamanlı stok sayıları

Sorun:

  • Cache hit rate: %3
  • İsteklerin %97'si: cache miss + yine de DB sorgusu
  • Her istek Redis'e ağ gidiş-dönüşünü ödedi: ~2ms
  • Artı serileştirme/ters serileştirme: ~5ms
  • Net sonuç: neredeyse her istekte ~7ms saf ek yük — cache'siz halinden daha yavaş

Neyi cache'lemeliydik:

  • Ürün kataloğu (okuma ağırlıklı, nadiren değişir)
  • Kategori ağacı (statik)
  • Feature flag'ler (global, nadiren değişir)
  • Hesaplanmış toplamlar (hesaplaması pahalı)

Cache matematiği:

Benefit per request = (hit_rate × db_latency_saved) - cache_overhead

The overhead applies to every request.
The saving applies only to hits.
If benefit < 0, the cache is hurting you.

Düzeltilmiş sürüm:

  • Uçucu veriyi cache'ten çıkardık
  • Statik içeriği uzun TTL ile ekledik
  • Hit rate: %3 → %85
  • P50 gecikme: 150ms → 40ms

Ders: Okuma ağırlıklı, nadiren değişen veriyi cache'leyin. Yazma ağırlıklı, uçucu veriyi değil. Altyapı eklemeden önce istek yolunu profillemek, DevOps çalışmalarımızda yaptığımız ilk iştir — en ucuz cache, hiç ihtiyaç duymadığınız cache'tir.

← Çı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 #Performans #Gecikme #Mimari