yapayzekapromptu
Yazılım'ya dön
Yazılım

Redis Önbellekleme Stratejisi için Claude prompt'u

Optimal modelClaude
Zorlukİleri
KategoriYazılım
Varyant3 adet
prompt.txt
Sen deneyimli bir backend mimarı ve performans mühendisisin. {proje_adi} uygulaması için Redis önbellekleme katmanını sıfırdan tasarla — strateji seçiminden production deployment'a kadar her adımı çalışır kodla göster.

## Proje Parametreleri
- **Backend Stack:** {backend_stack} (örn: "Python/FastAPI", "Node.js/Express", "Go/Gin", "Java/Spring Boot")
- **Veritabanı:** {veritabani} (örn: "PostgreSQL", "MySQL", "MongoDB")
- **Aylık Aktif Kullanıcı:** {kullanici_sayisi} (örn: "50K", "500K", "5M")
- **Kabul Edilebilir Gecikme:** {gecikme_hedefi} ms (örn: "50", "100", "200")
- **Kritik Varlıklar:** {varliklar} (örn: "kullanıcı profili, ürün kataloğu, oturum bilgisi")

---

## Adım 1 — Strateji Seçimi (Karar Matrisi)

Aşağıdaki dört stratejiyi karşılaştır ve {proje_adi} için en uygun ikisini öner. Her satır için {varliklar} varlıklarından biri özelinde somut gerekçe ver:

| Strateji | Ne Zaman Kullan | Cache-DB Tutarlılık | Yazma Yükü | {proje_adi} İçin? |
|----------|----------------|---------------------|------------|-----------------|
| Cache-Aside (Lazy Loading) | | | | |
| Write-Through | | | | |
| Write-Behind (Write-Back) | | | | |
| Read-Through | | | | |

**Seçilen strateji:** [strateji adı] — tek paragraf gerekçe.

---

## Adım 2 — Redis Veri Yapısı Tasarımı

{varliklar} için aşağıdaki tabloyu doldur:

| Varlık | Redis Veri Yapısı | Key Şablonu | TTL | Örnek Değer |
|--------|------------------|-------------|-----|-------------|
| [varlık 1] | String / Hash / List / Sorted Set / Set | `{proje_adi_lower}:{varlık}:{id}` | Xd/Xh/Xm | `{"id": 1, ...}` |
| [varlık 2] | | | | |
| [varlık 3] | | | | |

**Key namespace kuralları:**
- Ortam prefix'i: `prod:` / `staging:` / `dev:`
- Tam şablon: `{ortam}:{proje_adi_lower}:{varlık}:{id_veya_parametre}`
- Maksimum key uzunluğu: 100 karakter

---

## Adım 3 — Temel Cache İşlemleri ({backend_stack} Kodu)

{backend_stack} dilinde aşağıdaki fonksiyonları/metodları yaz:

```
get_cached(key)              → Redis'ten al; miss'te DB'den çek, cache'e yaz, döndür
set_cached(key, value, ttl)  → JSON serialize et, Redis'e yaz
invalidate(key)              → Tek key sil
invalidate_pattern(pattern)  → "prod:myapp:user:*" gibi wildcard ile toplu sil (SCAN tabanlı, KEYS kullanma)
```

Her fonksiyon için:
- Hata yönetimi: Redis bağlanamıyorsa uygulamayı durdurma — **graceful degradation** (DB'ye düş)
- Serialization: JSON; tarih/özel tip varsa custom encoder
- Connection pooling: min=5, max=20 bağlantı; idle timeout=300s

Ayrıca şu decorator'ı yaz:
```python
@cached(ttl=300, key_fn=lambda user_id: f"prod:myapp:user:{user_id}")
async def get_user(user_id: str) -> User: ...
```

---

## Adım 4 — Cache Invalidation Stratejisi

{varliklar} varlıklarından birini seçerek şu üç durumu {backend_stack} koduyla göster:

**4a. Tek kayıt güncelleme → cache invalidate:**
```
PUT /api/{varlik}/{id}  →  DB güncelle  →  Redis.delete(key)
```

**4b. Toplu güncelleme (örn. kategori altındaki tüm ürünler):**
```
Senaryo: bir kategori fiyatı değişti → o kategorideki tüm ürün cache'leri iptal
Yöntem: Tag-based invalidation (Redis Set'te key listesi tut) veya pattern delete
```
İkisini de göster; avantaj/dezavantaj bir satırda açıkla.

**4c. Event-driven invalidation:**
Veritabanı değişikliği → message queue (Redis Pub/Sub veya harici) → cache worker → invalidate
Kodu ve akış diyagramını (ASCII ok ile) göster.

---

## Adım 5 — Cache Stampede Önleme

Yüksek trafikte aynı anda çok sayıda istek boş cache'e çarparsa DB'ye aşırı yük biner. Şu iki tekniği {backend_stack} koduyla uygula:

**5a. Mutex Lock (Redis SET NX):**
```
if lock = redis.SET("lock:{key}", 1, NX, EX=5):
    data = db.fetch(...)
    redis.set(key, data, ttl)
    redis.delete("lock:{key}")
else:
    wait_and_retry(max_attempts=3)
```

**5b. Probabilistic Early Expiration (XFetch Algoritması):**
Gerçek TTL dolmadan önce olasılıksal yenileme — formülü ve {backend_stack} implementasyonunu göster.

Her tekniği ne zaman tercih etmeli? Bir satırda kural yaz.

---

## Adım 6 — Connection Pooling ve Yapılandırma

{backend_stack} için production-ready Redis bağlantı yapılandırması yaz:

```
max_connections: 20
min_idle_connections: 5
connect_timeout: 2s
socket_timeout: 1s
retry_on_timeout: true
retry_count: 3
health_check_interval: 30s
```

Ayrıca şu iki deployment senaryosu için bağlantı URL'si ve hangi durumda kullanılacağını göster:
- **Redis Sentinel** (yüksek erişilebilirlik, tek bölge)
- **Redis Cluster** (yatay ölçekleme, multi-shard)

---

## Adım 7 — Monitoring ve Cache Hit Rate Analizi

Aşağıdaki metrikleri nasıl toplayacağını göster:

| Metrik | Redis Komutu | Alarm Eşiği | Aksiyon |
|--------|--------------|-------------|--------|
| Cache hit rate | `INFO stats` → `keyspace_hits` / total | < %70 → alarm | TTL/strateji gözden geçir |
| Memory kullanımı | `INFO memory` → `used_memory_rss` | > %80 maxmemory | Eviction policy ayarla |
| Bağlantı sayısı | `INFO clients` → `connected_clients` | > max_connections × 0.9 | Pool büyüt |
| Gecikme (ms) | `LATENCY HISTORY command` | p99 > 10ms | Ağ/Redis konfigürasyon incele |

{backend_stack} dilinde bu metrikleri her 60 saniyede bir loglayan bir background task/cron yaz.

---

## Adım 8 — Cache Warming (Soğuk Başlatma Çözümü)

Uygulama yeniden deploy edildiğinde cache boş kalır → ilk istekler yavaş. Şu warm-up stratejisini uygula:

```
deploy tamamlandı
  → warm_cache() görevi tetikle (arka planda, async)
  → {varliklar} varlıklarının en sık erişilen %20'sini DB'den çekip cache'e yaz
  → İlerlemeyi logla: "Cache warm: 450/2000 kayıt yüklendi"
  → Tamamlandığında health endpoint'te is_cache_warm: true döndür
```

{backend_stack} dilinde bu warm-up fonksiyonunu yaz; batch boyutu 50, DB'ye max 5 paralel sorgu.

---

## Kısıtlar
- Redis bağlantısı kesilirse uygulama ÇÖKMEMELI; her cache işlemi try/except ile sarılmalı, hata loglanmalı, DB'ye düşülmeli
- Ham token, şifre veya PII (kişisel kimlik bilgisi) ASLA Redis'e yazılmasın
- Key'ler proje/ortam prefix'i ZORUNLU — multi-tenant veya multi-env çakışmasını önler
- TTL her varlık için ayrı tanımlanmalı; "hepsine 1 saat" yaklaşımı yok
- Tüm açıklamalar Türkçe, kod yorumları İngilizce

Bu ne işe yarar?

Redis önbellekleme stratejisi, veri yapısı tasarımı, TTL/invalidation, cache stampede önleme ve production deployment için çalışır kod üretin.

İlgili Promptlar