Cache stampede, hot key, dan cache berlapis

Sebelumnya, lesson 0014 membahas TTL, eviction, dan invalidation. TTL punya efek samping: saat key yang sangat populer kedaluwarsa, semua request untuk key itu tiba-tiba miss bersamaan. Lesson ini menutup modul Caching dengan tiga masalah yang muncul hanya di traffic tinggi, dan kapan Anda tidak perlu memikirkannya.

1. Cache stampede (thundering herd)

Cache stampede (juga disebut dog-piling atau thundering herd) terjadi ketika item cache yang populer kedaluwarsa, sehingga banyak request melihat miss dan meregenerasi item yang sama pada saat bersamaan. ^[1] Penyebabnya justru pola cache-aside biasa: cek cache, kalau miss hitung ulang dan simpan. Selama hitung ulang berlangsung, setiap request baru juga miss.

Angkanya cepat membesar. Paper yang sama memberi contoh item yang hitung ulangnya butuh satu menit dan diakses 10.000 proses per menit. ^[1] Hitung sendiri: key dibaca 5.000 kali per detik, hitung ulang 2 detik → sekitar 10.000 request bisa miss sebelum nilai baru tersimpan.

Empat mitigasi

1. Request coalescing. Gabungkan banyak miss untuk key yang sama menjadi satu request ke origin. RFC 9111 menyebutnya "collapse requests": menggabungkan beberapa request masuk menjadi satu request ke depan saat miss, sehingga beban origin turun. ^[2] Di nginx: proxy_cache_lock on mengizinkan hanya satu request pada satu waktu mengisi elemen cache baru; yang lain menunggu sampai respons ada di cache atau proxy_cache_lock_timeout. ^[3]
2. Lock di cache terdistribusi. Di level aplikasi, request yang miss mencoba mengambil lock dan hanya pemegang lock yang menghitung ulang. Redis SET lock:key 1 NX EX 10: NX hanya menulis kalau key belum ada ^[4], EX memberi lock TTL. Paper Vattani mencatat kelemahannya: request lain tidak punya nilai untuk dikembalikan (harus menunggu atau memakai nilai basi), ada write tambahan untuk lock, dan kalau pemegang lock gagal, tidak ada yang mengisi ulang sampai lock kedaluwarsa. ^[1]
3. Serve stale while revalidate. Sajikan nilai lama sambil satu proses me-refresh di belakang. HTTP: Cache-Control: max-age=600, stale-while-revalidate=30 berarti segar 600 detik, lalu boleh disajikan basi sampai 30 detik lagi sementara validasi asinkron dicoba. ^[5] nginx: proxy_cache_use_stale updating plus proxy_cache_background_update on. ^[3]
4. Early expiration dan jitter. Setiap request boleh memutuskan secara acak untuk menghitung ulang sedikit sebelum TTL habis, dengan peluang yang naik saat TTL mendekati habis; paper Vattani membuktikan versi eksponensialnya (XFetch) optimal. ^[1] Versi paling sederhana: tambahkan acak kecil pada TTL (TTL 300 ± 30 detik) supaya ribuan key yang diisi bersamaan tidak kedaluwarsa pada detik yang sama.

2. Hot key

Hot key adalah satu key yang menerima traffic jauh di atas key lain (profil selebritas, produk flash sale). Di cache terdistribusi, setiap key dipetakan ke satu node (hashing, lesson 0010), jadi menambah node tidak memecah beban satu key: node pemiliknya tetap kewalahan sementara node lain santai.

• Deteksi dulu. redis-cli --hotkeys mengambil sampel key untuk mencari hot key; opsi ini hanya bekerja bila maxmemory-policy memakai LFU. ^[6]
• Local cache di depan Redis. Simpan key panas di memori aplikasi dengan TTL pendek. Dokumentasi Redis: sebagian kecil data biasanya diakses jauh lebih sering, dan menyimpannya di memori lokal menurunkan latency sekaligus beban server; pasang TTL maksimum pada setiap key lokal. ^[7]
• Pecah key dengan suffix. Simpan N salinan (profil:42#1 … profil:42#8) yang tersebar ke node berbeda, baca salah satunya secara acak. Ide yang sama dipakai DynamoDB untuk write yang terkonsentrasi: tambahkan angka acak (mis. 1–200) sebagai suffix partition key supaya beban tersebar. ^[8] Biayanya: setiap update harus menulis ke N salinan.

3. Cache berlapis

Cache berlapis (multi-level cache) menumpuk beberapa cache, dari yang terdekat dan terkecil ke yang terjauh dan terbesar. Setiap lapisan menyaring miss sebelum sampai ke lapisan berikutnya.

CloudFront memakai regional edge cache sebagai lapisan tengah, dan Origin Shield menambah satu lapisan lagi: request untuk objek yang belum ada di cache-nya digabung dengan request lain untuk objek yang sama, sehingga bisa hanya satu request yang sampai ke origin. ^[9] Harganya: setiap lapisan menambah satu tempat data bisa basi. Local cache per instance cepat menjadi tidak konsisten antar-instance, sehingga perlu TTL lebih pendek. ^[10]

4. Kapan tidak perlu

Sinyal: proteksi stampede dibenarkan kalau QPS satu key × waktu hitung ulang menghasilkan banyak query serentak (5.000 QPS × 2 detik ≈ 10.000), atau metrik database menunjukkan lonjakan tepat saat TTL habis. Pada 10 QPS dengan hitung ulang 50 ms, miss bersamaan paling banyak satu atau dua query: biarkan saja. Pecah hot key hanya setelah --hotkeys atau metrik per node menunjukkan satu node jauh lebih sibuk dari yang lain.

Biaya dan risiko: lock menambah write dan titik gagal baru (pemegang lock crash) ^[1]; salinan hot key harus diperbarui semuanya; setiap lapisan cache tambahan menambah tempat data basi dan jalur invalidation yang harus dijaga. ^[10]

Alternatif lebih murah: jitter pada TTL (satu baris kode); stale-while-revalidate atau proxy_cache_lock di proxy yang sudah ada (konfigurasi, bukan komponen baru) ^[3]; dan untuk konten publik, biarkan CDN yang menyerap traffic sebelum memikirkan local cache sendiri.

Berikutnya, lesson 0016: modul Asinkron dimulai dengan message queue vs pub/sub. Modul Data dan Caching diuji bersama di review 0019.

Istilah: GLOSSARY.md (bagian "Caching") · Indeks: semua lesson System Design

Ada yang belum jelas? Tanyakan ke saya (agent) di terminal, misalnya: "Apa beda request coalescing dan lock?", "Bagaimana XFetch memutuskan kapan refresh lebih awal?"

Sumber: [1] Vattani et al. 2015, "Optimal Probabilistic Cache Stampede Prevention", PVLDB 8(8) · [2] RFC 9111: HTTP Caching · [3] nginx: Module ngx_http_proxy_module · [4] Redis docs: SET · [5] RFC 5861: HTTP Cache-Control Extensions for Stale Content · [6] Redis docs: redis-cli · [7] Redis docs: Client-side caching reference · [8] Amazon DynamoDB: Using write sharding to distribute workloads evenly · [9] Amazon CloudFront: Use Origin Shield · [10] Azure Architecture Center: Cache-Aside pattern