Strategi Caching Redis: Menghindari Cache Stampede & Thundering Herd Problem

Petaka Cache Stampede di Jam Sibuk

Bayangkan Anda memiliki halaman produk yang dikunjungi oleh 10.000 pengguna per detik. Data produk disimpan di Redis dengan masa TTL (Time-to-Live) 1 jam. Tepat di detik ke 3.600, data tersebut kedaluwarsa (expired).

Secara serentak, seluruh 10.000 koneksi mendapati cache kosong (cache miss) dan secara simultan membanjiri database SQL utama dengan query yang sama. Database kehabisan koneksi pool, CPU melonjak 100%, dan server tumbang. Fenomena ini disebut Cache Stampede atau Thundering Herd.

Solusi 1: Mutex Lock (Distributed Locking)

Hanya satu request pertama yang diizinkan mengambil data baru dari DB dan mengupdate Redis; request lainnya menunggu sejenak:

async function getCachedProduct(productId: string) {
  let data = await redis.get(`product:${productId}`);
  if (!data) {
    const lock = await redis.set(`lock:product:${productId}`, '1', 'NX', 'EX', 5);
    if (lock) {
      // Hanya worker ini yang mengeksekusi query database
      data = await db.queryProduct(productId);
      await redis.set(`product:${productId}`, JSON.stringify(data), 'EX', 3600);
      await redis.del(`lock:product:${productId}`);
    } else {
      // Worker lain tidur 50ms lalu coba baca cache kembali
      await sleep(50);
      return getCachedProduct(productId);
    }
  }
  return JSON.parse(data);
}

Solusi 2: Algoritma XFetch (Probabilistic Early Expiration)

Alih-alih menunggu cache kedaluwarsa secara kaku, algoritma XFetch menghitung kemungkinan memperbarui cache beberapa saat sebelum TTL habis berdasarkan beban traffic.