UNDER PRESSURE

Level 2 · Database adalah Leher Botol

Sesi 19: Menunda Pertanyaan ke Database: Redis Cache, Hit Ratio, & Thundering Herd

Bagaimana jika 10.000 orang menanyakan hal yang sama persis dalam satu detik — dan kita menanyakannya ke database 10.000 kali?

Sesi 19 / 343 menit baca

1. Bayangkan Jika

Sebuah perpustakaan memiliki satu petugas referensi. Setiap kali ada pengunjung bertanya "Di mana letak buku Sejarah Dunia?", petugas berjalan kaki 5 menit ke gudang bawah tanah untuk mengecek rak, lalu kembali menjawab. Jika 1.000 orang bertanya hal yang sama dalam satu jam, petugas pingsan karena kelelahan.

Petugas kemudian menempelkan satu lembar kertas memo (sticky note) di atas meja resepsionis: "Buku Sejarah Dunia ada di Rak 4B". Sekarang, 999 penanya berikutnya langsung membaca memo tersebut dalam tempo 1 detik tanpa membuat petugas melangkah satu langkah pun.

2. Apa yang Sebenarnya Terjadi

In-memory caching (Redis / Memcached) adalah peredam kejut paling ampuh untuk database:

  1. Pola Cache-Aside (Lazy Loading): - Aplikasi memeriksa Redis terlebih dahulu (GET key). - Cache Hit: Data ditemukan di RAM Redis -> Langsung kembalikan ke klien dalam tempo sub-milidetik (0.5 ms). - Cache Miss: Data tidak ada -> Aplikasi query ke Database (15–50 ms) -> Simpan hasil query ke Redis dengan waktu kedaluwarsa (TTL) -> Kembalikan data ke klien.

  2. Aritmatika Efektivitas Hit Ratio (H): - Response time efektif:

    T_{eff} = (H \times T_{cache}) + ((1 - H) \times T_{db})
    - Jika T_{cache} = 1\text{ ms}, T_{db} = 50\text{ ms}:

    • Hit Ratio 99% \rightarrow T_{eff} = (0.99 \times 1) + (0.01 \times 50) = \mathbf{1.49\text{ ms}} (Database hanya menerima 1% trafik!).
    • Hit Ratio 80% \rightarrow T_{eff} = (0.80 \times 1) + (0.20 \times 50) = \mathbf{10.8\text{ ms}} (Database dihantam 20% trafik, 20 kali lipat lebih berat!).

3. Tiga Cara Cache Membunuh Sistem

  1. Cache Stampede / Thundering Herd: - Satu key data yang sangat populer (misal: flash sale item) memiliki TTL 60 detik. - Di detik ke-60, TTL habis. Tepat di milidetik tersebut, ada 5.000 request bersamaan yang mengalami Cache Miss serempak. - Ke-5.000 request itu semuanya serentak mengirim query berat yang sama persis ke Database. Database seketika kolaps! - Solusi: Mutual Exclusion Lock (Mutex via Redis SETNX) atau Probabilistic Early Expiration (XFetch algorithm).

  2. Hot Key & Big Key: - Hot Key: Satu key diakses jutaan kali per detik, membuat satu core thread Redis di node tertentu mencapai 100% CPU. (Solusi: Local In-Memory Cache di Pod seperti Caffeine / Go-Cache). - Big Key: Key dengan payload JSON 50 MB. Serialisasi dan transfer jaringannya memblokir event loop Redis.

  3. Cold Start (Cache Kosong Pasca Restart): - Cluster Redis baru di-restart atau di-deploy baru. Seluruh cache kosong (H = 0\%). - Seluruh beban jutaan request langsung tembus menghantam database tanpa penyaring. - Solusi: Cache Warming (pra-populasi data populer sebelum membuka traffic gateway).

4. Nama Resminya

  • Cache-Aside / Read-Through: Pola pengambilan data melalui lapisan cache.
  • Cache Hit Ratio (H): Persentase request yang berhasil dilayani dari RAM cache.
  • TTL (Time-To-Live): Batas waktu umur simpan data sebelum dihapus otomatis.
  • Cache Stampede / Thundering Herd: Badai query ke database akibat key populer expired bersamaan.
  • Cache Warming / Pre-heating: Mengisi cache dengan data kritis sebelum sistem menerima trafik publik.

5. Di Dunia Kita

  • Redis Cluster vs Sentinel: Sentinel untuk High Availability failover master-replica; Cluster untuk sharding data RAM secara horizontal lewat 16.384 hash slots.
  • Two-Tier Caching (L1 + L2): L1 di memory pod aplikasi (sub-mikrodetik) + L2 di Redis terpusat (sub-milidetik) + L3 di Database.

6. Lensa Performance Tester

Metrik dan pengujian krusial: 1. Hit Ratio Sensitivity Test: Simulasikan degradasi Hit Ratio dari 99% turun ke 85%. Berapa batas kapasitas database sebelum runtuh? 2. Key Expiration Stampede Simulation: Uji beban saat key viral di-invalidate atau expired. Apakah mutex lock berfungsi mencegah thundering herd? 3. Cold Cache Load Test: Mulai pengujian beban dengan status Redis kosong untuk mengukur daya tahan database saat skenario restart massal.

7. Pertanyaan untuk Ronde Berikutnya

Cache dan read replica sudah membebaskan database dari 98% beban baca. Tapi bagaimana jika volume data tulis transaksi kita sudah mencapai puluhan terabyte hingga satu disk database terbesar di dunia pun tidak lagi muat?

Jawabannya ada di Sesi 20: Kalau Satu Database Tidak Cukup (Database Sharding & Partitioning).