Pilih pekerjaan yang ingin dihindari
Cache itu cara menghindari pekerjaan. Tentukan dulu pekerjaan mana yang mahal, lalu pilih lapisan cache yang paling dekat dengan pembaca tapi masih aman.
Pertanyaan
Pekerjaan mahal apa yang sebenarnya berulang, dan di lapisan mana ia paling murah dihindari?
Setelah baca ini, kamu bisa menunjuk satu pekerjaan berulang, memilih lapisan cache untuknya, dan menghitung hit ratio minimum supaya sumber datanya aman.
Prasyarat dan contoh
Kamu sudah paham jalur request dari browser sampai respons (M02), kontrak API dan header dasar (M03), serta dasar indeks dan query (M04). Kamu juga sudah bisa menghitung utilisasi sebuah komponen (M01.03).
Contoh: halaman detail produk di toko online. Puncaknya 1.200 request per detik, 95% baca. Tiap request menjalankan satu query ke basis data seharga rata-rata 12 ms, dan basis data hanya sanggup 400 query per detik. Tanpa cache, kebutuhan 1.200 query per detik, tiga kali kapasitas.
Reaksi pertama biasanya "pasang Redis". Padahal pertanyaan yang benar belum diajukan: pekerjaan apa yang mau dihindari? Query ke basis data, render HTML, panggilan ke layanan pihak ketiga, atau transfer byte lewat jaringan? Tiap pekerjaan punya lapisan cache yang berbeda.
Mekanisme
Urutkan lapisan dari yang paling dekat dengan pembaca. Makin dekat, makin banyak pekerjaan yang dihindari, tapi makin sulit kamu kendalikan isinya.
| Lapisan | Pekerjaan yang dihindari | Siapa yang mengontrol isinya | | ---------------------- | ------------------------------------ | --------------------------------- | | Klien (browser, app) | Seluruh request ke jaringan | Hampir tidak ada setelah terkirim | | CDN | Request ke origin dan transfer jauh | Kamu, lewat header dan purge | | Memori proses lokal | Panggilan jaringan ke cache/DB | Per instance, tidak sinkron | | Cache bersama (Redis) | Query ke basis data | Kamu, terpusat | | Buffer basis data | Baca disk | Basis data, otomatis |
Klien dan CDN cocok untuk respons yang sama untuk banyak orang dan jarang berubah:
gambar produk, CSS, halaman katalog publik. Kendalinya lewat Cache-Control. max-age=3600
berarti browser tidak menanyakan lagi selama satu jam, dan kamu tidak bisa menariknya kembali.
Memori proses lokal adalah yang tercepat, kira-kira mikrodetik. Harganya: kalau ada 20 instance, ada 20 salinan yang bisa berbeda, dan tiap instance mengisi cache-nya sendiri sehingga beban ke basis data naik sebanyak jumlah instance. Cocok untuk data kecil yang jarang berubah, seperti konfigurasi atau daftar negara.
Cache bersama menambah satu hop jaringan, kira-kira 0,3 sampai 1 ms di jaringan yang sama, tapi semua instance melihat data yang sama. Ini pilihan umum untuk hasil query yang mahal.
Buffer basis data sudah ada tanpa kamu pasang. Memperbesarnya sering lebih murah daripada menambah cache baru, dan ia tidak punya masalah kebenaran sendiri karena basis data yang mengelolanya.
Untuk memutuskan apakah cache cukup, hitung hit ratio minimum. Kalau h adalah proporsi request
yang dilayani cache:
bebanSumber = rps × (1 − h)
hMinimum = 1 − (kapasitas × utilisasiTarget) / rps
Untuk toko tadi dengan target utilisasi 60%: 1 − (400 × 0,6) / 1.200 = 0,8. Hit ratio
minimal 80%, dan itu belum memberi ruang kalau cache mati.
Saat rancangan ini gagal
- Cache menutupi masalah di bawahnya. Query 12 ms yang sebenarnya bisa 1 ms dengan indeks malah di-cache. Begitu cache mati, masalah aslinya muncul tiba-tiba.
- Hit ratio rendah. Kalau 60% request menanyakan item yang hanya dilihat sekali (long tail), cache menambah satu hop tanpa mengurangi banyak beban. Ukur sebaran akses sebelum memasang.
- Data berubah, cache tidak tahu. Harga di CDN yang di-cache satu jam tetap tampil lama setelah kamu mengubahnya. Lapisan yang lebih dekat ke pembaca lebih sulit dibersihkan.
- Cache lokal yang tidak sinkron. Dua instance menampilkan stok berbeda pada pengguna yang sama saat ia me-refresh.
- Cache jadi dependensi tersembunyi. Sistem hanya lulus uji beban kalau cache hangat. Itu dibahas di M06.06.
Contoh tandingan: laporan keuangan per pengguna di-cache di CDN dengan key URL saja. Pengguna B menerima laporan pengguna A. Data yang pribadi tidak boleh masuk lapisan bersama tanpa key yang membedakannya (M06.02).
Latihan
Endpoint daftar artikel menerima 3.000 request per detik pada puncak. Basis data sanggup 500 query per detik, dan kamu ingin utilisasinya tidak lebih dari 60%. Daftar artikel sama untuk semua pengunjung dan berubah rata-rata sekali per jam.
- Hitung hit ratio minimum.
- Pilih lapisan cache dan alasannya.
- Sebut satu risiko pada pilihanmu.
Lihat pembahasan
bebanMaksimum = 500 × 0,6 = 300 query/detik
hMinimum = 1 − 300 / 3.000 = 0,9
Hit ratio minimal 90%. Karena isinya sama untuk semua pengunjung dan berubah sekali per jam,
CDN dengan max-age pendek (misalnya 60 detik) menghindari paling banyak pekerjaan: request tidak
sampai ke aplikasi sama sekali. Cache bersama di belakangnya bisa jadi lapisan kedua.
Risiko: artikel yang baru diterbitkan baru tampil setelah sampai 60 detik. Kalau itu tidak bisa
diterima, tambahkan purge ke CDN saat terbit, dan tetap simpan max-age sebagai batas atas kalau
purge gagal.
Terkait
- Lanjut ke M06.02 Rancang key cache.
- M01.03 Hitung kebutuhan server menjelaskan cara menghitung utilisasi yang dipakai di sini.
- Header cache HTTP dan indeks dibahas di M03 dan M04, yang belum tersedia di sini. Lab L06 dan rancangan D02 belum tersedia.
Catatan
- Asumsi: beban baca merata di sedikit key populer, dan satu query setara satu request.
- Yang tidak dibahas: detail header HTTP, ukuran memori, dan kebijakan invalidasi.
- Angka latensi cache bersama adalah orde besar umum, bukan hasil pengukuran sistem tertentu.
- Terakhir ditinjau: 26 Oktober 2026.