Redis Cache ile API Hızlandırma: 10 Dakikada

Meta Description

Redis cache ile API’yi hızlandırın, veritabanı yükünü azaltın. Node.js örneğiyle TTL, invalidation ve pratik adımlar.

Giriş (Introduction)

Bir API’nin yavaşlamasının en yaygın nedeni genelde “kod kötü” olması değil; aynı verinin tekrar tekrar veritabanından okunmasıdır. Ürün listesi, popüler içerikler, kullanıcı profili gibi sık istenen çıktılar, her istekte DB’ye gidince gecikme artar ve maliyet büyür.

Bu yazıda Redis cache kullanarak API performansını nasıl gözle görülür şekilde artırabileceğinizi, hangi verileri cache’lemenin mantıklı olduğunu ve “cache bozulursa ne olur?” gibi kritik detayları pratik bir Node.js + Express örneğiyle adım adım öğreneceksiniz.

Redis Cache Nedir ve Neden Önemli?

Redis cache, bellekte çalışan çok hızlı bir veri deposudur. API katmanında “önbellek” olarak kullanıldığında, veriyi DB yerine Redis’ten servis ederek yanıt süresini düşürür.

Bunu neden yapmalıyım?

• Daha düşük gecikme (latency): Bellekten okuma, DB sorgusundan çok daha hızlıdır.
• Veritabanı yükünü azaltma: Aynı sorgunun tekrar tekrar çalışmasını engellersiniz.
• Daha az maliyet: Daha az DB kaynağı tüketimi = daha az altyapı gideri.
• Daha stabil trafik yönetimi: Ani trafik artışlarında DB’niz “çökmek” yerine cache sayesinde ayakta kalır.

LSI (ilişkili) kavramlar: API performansı, caching stratejisi, TTL, cache invalidation, rate limiting, CDN, veritabanı yükü azaltma

Hangi Veriler Cache’lenmeli? (Doğru Hedefi Seçin)

Cache herkes için her yerde doğru çözüm değildir. En iyi sonuçlar şu tip verilerde gelir:

• Okuma ağırlıklı veriler (read-heavy):
  • Ürün listesi, kategori sayfaları
  • Popüler içerikler
  • Konfigürasyon / feature flag çıktıları
• Sık tekrar eden sorgular:
  • “Son 24 saatin en çok satanları”
• Kısa süre toleransı olan veriler:
  • 30 saniye / 5 dakika gecikmeli güncellense sorun olmayan içerikler

Cache’lemek riskli olabilecek veriler

• Anlık doğruluk isteyen finansal veriler
• Çok sık güncellenen ve tutarlılık gerektiren stok/ödeme akışları

Redis Cache Stratejileri: TTL ve Invalidation

Cache’in en kritik kısmı “nasıl güncel kalacağıdır”. İki temel yaklaşım:

1) TTL (Time To Live)

Cache kaydına bir ömür biçersiniz. Süre dolunca Redis otomatik siler.

• Örnek: product:list anahtarını 60 saniye tut

2) Cache Invalidation (Geçersiz kılma)

Veri değiştiği an cache’i silersiniz.

• Örnek: Ürün güncellendiğinde product:123 cache’ini temizle

Kısa karşılaştırma tablosu

Adım Adım: Node.js + Express ile Redis Cache Kurulumu

Bu bölümde Redis cache ile bir endpoint’i hızlandıracağız.

1) Kurulum

Gerekli paketler:

npm i express redis

Redis’i lokal çalıştırmak isterseniz (Docker):

docker run -p 6379:6379 --name redis-cache -d redis:7

2) Basit bir cache middleware yazalım

Aşağıdaki örnekte:

• Cache varsa direkt Redis’ten dönüyoruz
• Yoksa “DB simülasyonu” yapıp sonucu cache’liyoruz

import express from "express";
import { createClient } from "redis";

const app = express();

const redis = createClient({
  url: process.env.REDIS_URL || "redis://localhost:6379",
});

redis.on("error", (err) => console.error("Redis error:", err));
await redis.connect();

// DB simülasyonu (örnek olsun diye gecikmeli)
async function fakeDbQuery() {
  await new Promise((r) => setTimeout(r, 300));
  return {
    items: [
      { id: 1, name: "Klavye", price: 999 },
      { id: 2, name: "Mouse", price: 499 },
    ],
    generatedAt: new Date().toISOString(),
  };
}

app.get("/api/products", async (req, res) => {
  const cacheKey = "products:list";

  // 1) Cache kontrol
  const cached = await redis.get(cacheKey);
  if (cached) {
    return res.json({
      source: "redis-cache",
      data: JSON.parse(cached),
    });
  }

  // 2) Cache yoksa DB’den getir
  const data = await fakeDbQuery();

  // 3) Cache’e yaz (TTL: 60 saniye)
  await redis.set(cacheKey, JSON.stringify(data), {
    EX: 60,
  });

  return res.json({
    source: "db",
    data,
  });
});

app.listen(3000, () => console.log("API running: http://localhost:3000"));

3) Test

İlk istek “db” kaynağından gelir, sonraki istekler 60 saniye boyunca redis-cache’ten döner.

• İlk çağrı: GET /api/products → source: db
• İkinci çağrı: GET /api/products → source: redis-cache

Cache Key Tasarımı: En Sık Yapılan Hata

Redis cache performansını “key tasarımı” belirler.

İyi bir key formatı

• Kaynak adı + filtre + versiyon gibi parçalar içerir

Örnekler:

• products:list:v1
• products:list:category=7:v1
• user:profile:42:v1

Neden önemli?

• Yanlış key = yanlış veri (özellikle filtreli listelerde)
• Versiyon (v1) = şema değiştiğinde güvenli geçiş

İpucu: Filtre parametrelerini key’e eklemeden cache’lerseniz, farklı kullanıcılar aynı cached çıktıyı görür ve “bug var” sanırsınız.

Gerçek Hayattan Senaryo: E-ticarette Ürün Listeleme

Diyelim ki bir girişim kurdunuz ve ana sayfada “Popüler Ürünler” listesi var.

• Dakikada 10.000 istek geliyor
• Liste 1 dakikada bir güncellenebilir (tam anlık olması şart değil)

Redis cache ile:

• DB sorgusu dakikada 10.000 yerine dakikada ~1 (cache miss olduğunda)
• Ortalama yanıt süresi ciddi düşer
• DB bağlantı havuzu daha stabil kalır

Ne zaman cache’i temizlemeli?

• Ürün fiyatı/isim güncellendiğinde ilgili liste key’ini silebilirsiniz:

await redis.del("products:list");

Bu yaklaşım, TTL’ye ek bir güvenlik katmanı sağlar.

Üretimde Dikkat Edilecekler (Kısa Kontrol Listesi)

• Cache stampede (aynı anda cache miss):
  • Çok trafik alan endpoint’lerde “lock” veya stale-while-revalidate düşünün.
• Serileştirme maliyeti:
  • Büyük JSON’ları cache’lemek bazen CPU’ya yük olur.
• Gözlemlenebilirlik:
  • Cache hit/miss oranlarını ölçün.

Mini metrikler:

• Cache hit rate (%)
• Ortalama latency (p50/p95)
• Redis memory usage

Sık Sorulan Sorular (FAQ)

1) Redis cache kullanmak API’yi her zaman hızlandırır mı?

Hayır. Okuma ağırlıklı ve sık tekrar eden isteklerde büyük fark yaratır; sürekli değişen veride faydası düşer.

2) TTL kaç saniye olmalı?

Tek bir doğru yok. İçeriğin güncellik ihtiyacına göre 30 sn – 10 dk arası sık kullanılır. Kritik veride daha düşük tutulur.

3) Cache’lenen veri yanlış/eskimiş olursa ne olur?

TTL bitene kadar eski veri dönebilir. Bunu azaltmak için invalidation (veri değişince cache silme) eklenir.

4) Redis mi yoksa CDN mi kullanmalıyım?

Statik içerik (görsel, JS, CSS) için CDN; dinamik API yanıtları için çoğunlukla Redis cache daha uygundur. İkisi birlikte de kullanılabilir.

Sonuç

Redis cache ile API performansını artırmak, veritabanı yükünü azaltmak ve ani trafik artışlarında sistemi daha dayanıklı hale getirmek mümkündür. Bu yazıda TTL ve invalidation mantığını gördünüz, Node.js + Express ile 10 dakikada çalışan bir cache örneği kurdunuz.

Bir sonraki adım: Kendi projenizde en çok trafik alan 1 endpoint’i seçin, cache hit/miss ölçümü ekleyin ve sonucu yorumlarda paylaşın. İsterseniz kullandığınız stack’i yazın, size uygun cache key ve TTL önerisiyle geri döneyim.