Di mana cache berada, dan empat pola mengisinya
Lesson pertama modul Caching: lapisan cache dari browser sampai Redis, lalu cache-aside, read-through, write-through, dan write-behind beserta trade-off-nya
Sebelumnya, Review 1 menutup modul Fondasi dan Skalabilitas. Di tangga skala, cache adalah anak tangga sesudah "ukur, lalu perbaiki kode/query/index" dan sebelum scale vertical atau read replica: murah, tapi membawa masalah baru (data basi). Lesson ini menjawab dua pertanyaan: cache diletakkan di mana, dan siapa yang mengisinya.
1. Di mana cache berada
"Cache" bukan satu kotak. Sepanjang perjalanan request ada beberapa tempat menyimpan salinan jawaban, dan makin dekat ke user, makin murah satu hit:
- Browser (private cache). HTTP caching diatur header seperti
Cache-Control: max-age. RFC 9111 membedakan private cache (milik satu user, mis. browser) dan shared cache (dipakai banyak user, mis. CDN atau proxy). [1] - CDN di edge. Shared cache dekat user. CloudFront menyarankan origin menambah
Cache-Control max-ageuntuk menaikkan cache hit ratio (porsi request yang dilayani dari cache, tanpa ke origin). [2] - Reverse proxy. nginx bisa menyimpan respons upstream; direktif
proxy_cache"defines a shared memory zone used for caching". [3] - Local cache in-process. Map di memori proses aplikasi. Dokumentasi Redis: akses memori lokal lebih cepat beberapa orde besaran dibanding layanan lewat jaringan seperti database. [4]
- Distributed cache. Redis atau Memcached terpisah yang dipakai bersama oleh semua instance. Local cache bersifat private per instance, sehingga salinan antar-instance cepat tidak konsisten; Azure menyarankan shared/distributed cache untuk kasus itu. [5]
Aturan praktis: konten publik yang sama untuk semua user (gambar, CSS, halaman katalog anonim) cukup diberi header HTTP, tanpa komponen baru. Data dinamis per user (keranjang, profil) disimpan di cache yang dikontrol aplikasi.
Latihan 1 — Lokasi cache
Jawab tanpa scroll ke atas. Soal yang sama akan muncul lagi, diacak, di review 0019.
Kuis di lesson ini adalah feedback cepat, bukan bukti penguasaan; yang dicatat hanya hasil review 0019.
2. Empat pola: siapa yang membaca dan menulis database
Untuk cache yang dikontrol aplikasi, pertanyaannya: saat miss, siapa yang mengambil data dari database? Saat write, kapan cache diperbarui?
Cache-aside (lazy loading): default yang paling sering
Aplikasi yang memegang kendali: coba baca cache; kalau miss, ambil dari data store, taruh di cache, kembalikan. Saat write, aplikasi mengubah data store lalu meng-invalidate (menghapus) item di cache. [5] Urutannya penting: update database dulu, baru hapus cache. Kalau cache dihapus dulu, ada jendela waktu ketika request lain miss, membaca nilai lama, dan menaruhnya kembali ke cache. [5]
Dokumentasi ElastiCache menyebut kelebihannya: hanya data yang diminta yang di-cache, dan node cache yang mati tidak fatal (aplikasi tetap jalan, hanya lebih lambat). Kekurangannya: setiap miss berarti tiga trip (baca cache, query database, tulis cache), dan data bisa basi karena cache tidak ikut diperbarui saat database berubah. [6]
Read-through, write-through, write-behind: cache yang mengurus database
Beberapa produk cache (contoh: Oracle Coherence) bisa memegang "loader" ke database sendiri. [7] Azure menyebut cache-aside sebagai cara meniru read-through kalau cache Anda tidak menyediakannya. [5]
| Pola | Cara kerja | Kelebihan | Biaya / risiko |
|---|---|---|---|
| Cache-aside | aplikasi baca DB saat miss, isi cache; write → update DB, hapus key | sederhana, cache mati tidak fatal | miss = 3 trip; data bisa basi sampai TTL/hapus |
| Read-through | aplikasi hanya bicara ke cache; saat miss, cache memanggil loader ke DB | kode aplikasi lebih bersih | butuh produk cache yang mendukungnya |
| Write-through | write ke cache dan DB dalam satu operasi; selesai setelah DB tersimpan | cache tidak basi setelah write | setiap write dua trip; cache terisi data yang tak pernah dibaca |
| Write-behind | write ke cache, DB ditulis asinkron setelah jeda lewat antrean | write cepat, beberapa update digabung ("write-coalescing") | data bisa hilang sebelum flush; update DB bisa tidak berurutan |
Sumber tabel: Coherence untuk read-through ("Coherence automatically delegates to the CacheStore"), write-through (put "does not return" sampai data tersimpan di data source), dan write-behind (ditulis "asynchronously ... after a configured delay"; cache menjadi system of record sampai antrean ditulis) [7]; ElastiCache untuk write-through ("data in the cache is never stale", setiap write dua trip, cache churn) [6]; Azure untuk perbandingan cache-aside vs write-through: write-through membuat pembaca melihat nilai baru tepat setelah write berhasil. [5]
Yang perlu diucapkan di interview: cache-aside + TTL sebagai default. Write-through bila pembacaan setelah write harus langsung segar. Write-behind hanya bila write sangat banyak dan kehilangan beberapa detik data bisa diterima (mis. counter view), bukan untuk pembayaran.
Latihan 2 — Empat pola
Jawab tanpa scroll ke atas. Soal yang sama akan muncul lagi, diacak, di review 0019.
3. Kapan tidak perlu
Sinyal yang membenarkan cache: rasio baca:tulis tinggi (mis. 100:1), data yang sama dibaca berulang (hit ratio yang diharapkan tinggi), dan p99 atau CPU database masih tinggi setelah query dan index diperiksa. Untuk 1.000 user aktif harian (di bawah 1 QPS rata-rata, lesson 0004), database tanpa cache sudah cukup.
Biaya dan risiko: satu komponen lagi untuk dijalankan dan dipantau, data basi, dan konsistensi yang tidak dijamin: cache-aside "doesn't guarantee consistency between the data store and the cache". [5] Azure juga mendaftar kapan pola ini tidak cocok: data sensitif atau terkait keamanan, dataset statis yang muat di memori (cukup diisi saat startup), dan ketika sebagian besar request tidak pernah hit, sehingga biaya cek dan isi cache melebihi manfaatnya. [5]
Alternatif lebih murah: baca query plan dengan EXPLAIN dan tambah index yang hilang [8];
pasang header Cache-Control supaya browser dan CDN yang menyimpan konten publik [1];
atau local cache kecil untuk data yang hampir tidak pernah berubah (daftar negara, konfigurasi), tanpa server cache baru.
Latihan lisan — Ucapkan dengan suara keras
Pasang timer dan jawab dengan suara keras, seolah sedang interview. Jangan buka jawaban contoh sebelum selesai.
"Katalog produk Anda read-heavy dan database mulai lambat. Pola cache apa yang Anda pakai, bagaimana alur baca dan tulisnya, dan kapan Anda tidak memakai cache sama sekali?" (60 detik)
Bandingkan dengan jawaban contoh dan checklist-nya
"Pertama saya ukur: kalau p99 lambat karena query tanpa index, saya perbaiki query dulu, itu lebih murah. Kalau rasio baca:tulis tinggi, misalnya 100:1, dan data yang sama dibaca berulang, saya pakai cache-aside di Redis bersama: baca cache, kalau miss baca database lalu isi cache dengan TTL. Saat write, update database dulu lalu hapus key-nya. Write-through membuat cache selalu segar tapi setiap write jadi dua trip; write-behind cepat tapi bisa kehilangan data kalau cache mati sebelum flush, jadi tidak untuk katalog berharga. Gambar produk cukup diberi header Cache-Control supaya browser dan CDN yang menyimpannya."
Checklist: apakah Anda menyebut…
- cache-aside: baca cache, miss → baca database → isi cache?
- urutan write: update database dulu, lalu hapus key cache?
- perbandingan dengan write-through (selalu segar, dua trip) atau write-behind (cepat, risiko data hilang)?
- TTL sebagai pengaman terhadap stale data?
- lokasi: header HTTP/CDN untuk konten publik, cache bersama untuk data dinamis?
- angka yang membenarkan cache (rasio baca:tulis, hit ratio, p99) setelah query/index diperiksa?
Lulus jika minimal 4 dari 6.
Berikutnya, lesson 0014: berapa lama data boleh tinggal di cache (TTL), apa yang dibuang saat memori penuh (LRU/LFU), dan bagaimana menghapus data basi.
Istilah: GLOSSARY.md (bagian "Caching") · Indeks: semua lesson System Design
Ada yang belum jelas? Tanyakan ke saya (agent) di terminal, misalnya: "Kapan read-through lebih baik daripada cache-aside?", "Kenapa delete key saat write, bukan langsung set nilai baru?"
Sumber: [1] RFC 9111: HTTP Caching · [2] Amazon CloudFront: Increase the cache hit ratio · [3] nginx: Module ngx_http_proxy_module · [4] Redis docs: Client-side caching reference · [5] Azure Architecture Center: Cache-Aside pattern · [6] Amazon ElastiCache: Caching strategies · [7] Oracle Coherence 14.1.1: Caching Data Sources · [8] PostgreSQL: Using EXPLAIN