Cache sering dijual sebagai jawaban paling cepat buat performance: taruh di Redis, hit database lebih sedikit, response lebih ngebut. Tapi ada sisi yang sering kelewat: cache juga makan memori, dan memori di cloud itu biaya nyata.
Artikel ini membahas pelajaran dari riset Google Research tentang linear elastic caching: cara mikir cache bukan cuma dari sisi cepat atau lambat, tapi dari total biaya antara menyimpan data di memori dan menanggung cache miss. Buat developer backend, startup kecil, atau builder yang mulai peduli cloud bill, poin pentingnya sederhana: sebelum nambah cache, lu perlu tahu apa yang sebenarnya lu optimalkan.
Apa itu cache, dalam bahasa sederhana?
Cache adalah tempat penyimpanan sementara buat data yang sering diakses, biasanya lebih cepat daripada sumber aslinya. Contohnya: hasil query database, response API, session, file statis, atau data konfigurasi yang sering dibaca.
Tujuan cache biasanya jelas: mengurangi latency dan beban sistem utama. Kalau user minta data yang sama berkali-kali, sistem nggak perlu menghitung atau mengambil ulang dari tempat yang lebih lambat.
Masalahnya, cache bukan ruang gratis. Data yang disimpan di memori punya harga. Kalau cache terlalu kecil, miss rate naik dan sistem sering balik ke database. Kalau cache terlalu besar, response mungkin lebih cepat, tapi bill memori bisa bengkak pelan-pelan.
Pelajaran utama dari Google: cache itu problem ekonomi
Google Research menerbitkan artikel tentang linear elastic caching, pendekatan yang memodelkan eviction cache seperti ski rental problem. Intinya: sistem perlu memutuskan kapan lebih murah untuk “menyewa” akses ulang dari backend, dan kapan lebih masuk akal “membeli” ruang memori dengan menyimpan data lebih lama.
Ini menarik karena cara pikirnya beda dari nasihat cache yang biasa kita dengar. Banyak developer mulai dari pertanyaan, “Cache size berapa yang aman?” Padahal pertanyaan yang lebih sehat adalah: “Berapa biaya memori lu, berapa biaya miss lu, dan pola akses data lu seperti apa?”
Google menekankan bahwa sistem modern harus menyeimbangkan dua biaya: memory footprint dan cache misses. Memory footprint berarti biaya menyimpan item di cache. Cache miss berarti biaya saat item tidak ada di cache dan sistem harus mengambil atau menghitung ulang dari sumber aslinya.
Kenapa fixed-size cache sering terasa gampang, tapi belum tentu optimal
Banyak sistem memakai batas cache tetap: misalnya 512 MB, 2 GB, atau 10 GB. Ini praktis karena gampang dikonfigurasi dan gampang dijelaskan ke tim.
Tapi fixed-size cache punya kelemahan: ukuran yang pas hari ini belum tentu pas besok. Traffic berubah. Pola akses user berubah. Data yang dulu sering dipakai bisa jadi dingin. Data baru bisa mendadak panas. Kalau cache lu tidak ikut membaca perubahan ini, ada dua risiko:
- Terlalu kecil: cache sering miss, database/API utama tetap kena beban besar.
- Terlalu besar: lu membayar memori buat data yang jarang dipakai.
Di project kecil, efeknya mungkin belum terasa. Tapi di sistem yang traffic-nya tinggi, selisih beberapa GiB memori yang terus menyala bisa jadi biaya bulanan yang lumayan. Apalagi kalau cache berjalan di managed service, multi-region, atau environment yang autoscale.
Eviction policy: siapa yang dikeluarin saat cache penuh?
Saat cache penuh, sistem harus memilih data mana yang dibuang. Ini disebut eviction. Redis, misalnya, punya beberapa policy seperti LRU dan LFU. LRU membuang item yang paling lama tidak dipakai. LFU mempertimbangkan frekuensi akses.
Policy seperti LRU dan LFU berguna, tapi tetap punya asumsi. LRU menganggap data yang lama tidak disentuh kemungkinan tidak dibutuhkan lagi. LFU menganggap data yang sering dipakai kemungkinan tetap penting. Dalam banyak kasus, asumsi ini cukup bagus. Tapi kalau lu ingin mengoptimalkan biaya cloud, “cukup bagus” kadang belum cukup.
Yang bikin riset Google menarik adalah pendekatannya lebih cost-aware. Bukan cuma “item mana yang paling lama tidak dipakai”, tapi “apakah menyimpan item ini masih lebih murah daripada risiko miss nanti?”
Analogi ski rental problem buat backend developer
Ski rental problem adalah masalah klasik: kalau lu main ski beberapa kali, lebih murah sewa alat atau beli alat sendiri? Kalau cuma sekali, sewa lebih masuk akal. Kalau sering, beli lebih murah dalam jangka panjang. Tantangannya: lu tidak selalu tahu dari awal bakal main berapa kali.
Cache punya dilema mirip. Menyimpan data di memori itu seperti membeli alat. Mengambil ulang data saat miss itu seperti menyewa. Kalau item akan sering dipakai lagi, simpan di cache masuk akal. Kalau item tidak akan dipakai lagi, menyimpannya cuma membuang memori.
Masalahnya, sistem tidak punya bola kristal. Dia cuma bisa membaca history akses dan membuat prediksi. Di sinilah pendekatan elastic dan lightweight machine learning bisa masuk: bukan untuk bikin sistem terlihat canggih, tapi untuk mengambil keputusan eviction yang lebih ekonomis.
Checklist sebelum lu nambah cache
Sebelum reflek menaikkan ukuran Redis atau menambah layer cache baru, coba jawab pertanyaan ini:
- Apa yang mahal? Latency, query database, API pihak ketiga, CPU, atau memori?
- Berapa cache hit rate sekarang? Kalau belum diukur, lu belum tahu masalahnya cache size atau pola akses.
- Berapa biaya cache miss? Miss ke database lokal beda dengan miss ke API berbayar atau query analitik berat.
- Data mana yang aman di-cache? Jangan asal cache data sensitif, personal, atau state yang cepat berubah.
- TTL lu masuk akal nggak? TTL terlalu pendek bikin miss tinggi; TTL terlalu panjang bisa bikin user lihat data basi.
- Ada invalidation plan? Cache cepat jadi musuh kalau tim tidak tahu kapan data harus dibuang.
- Metric-nya kelihatan? Pantau hit rate, miss rate, eviction count, memory usage, latency, dan biaya.
Contoh kasus kecil: cache yang kelihatan murah tapi diam-diam boros
Bayangin lu bikin dashboard internal. Awalnya, query ke database lambat. Solusi cepatnya: cache hasil query selama 10 menit. Response jadi ngebut, semua senang.
Lalu dashboard makin banyak dipakai. Filter bertambah. Setiap kombinasi filter membuat key cache baru. Cache size dinaikkan karena miss rate naik. Beberapa minggu kemudian, bill naik, tapi tim masih merasa “cache kan bikin cepat”.
Di titik itu, masalahnya mungkin bukan kurang cache. Bisa jadi key design terlalu granular, TTL terlalu panjang, query perlu dipecah, atau data agregasi perlu disimpan terpisah. Nambah memori memang bisa menutup gejala, tapi belum tentu memperbaiki desain.
Kapan cukup pakai cara sederhana?
Artikel Google membahas konteks riset dan workload produksi skala besar. Jadi jangan dibaca sebagai perintah bahwa semua aplikasi kecil harus bikin elastic caching sendiri.
Untuk banyak project, langkah sederhana sudah cukup:
- Mulai dari TTL yang jelas.
- Pakai LRU/LFU bawaan Redis sesuai pola akses.
- Tambahkan metric hit/miss sejak awal.
- Batasi key cardinality supaya cache tidak meledak.
- Review biaya memori setiap kali traffic berubah besar.
Yang penting bukan langsung meniru arsitektur Google. Yang penting adalah cara mikirnya: cache punya tradeoff, dan tradeoff itu bisa diukur.
Takeaway buat builder
Menurut gua, pelajaran paling berguna dari linear elastic caching bukan “pakai machine learning buat cache”. Pelajaran utamanya: performance engineering tanpa cost awareness bisa bikin lu menang di latency, tapi kalah di invoice.
Cache itu alat, bukan tombol ajaib. Dia bisa bikin app terasa cepat, tapi dia juga bisa menyembunyikan desain query yang buruk, key yang kebanyakan variasi, atau kebiasaan over-provisioning yang tidak pernah diaudit.
Kalau lu lagi membangun produk, especially yang mulai punya user beneran, jangan cuma tanya “bisa lebih cepat nggak?” Tanya juga: “lebih cepatnya dibayar pakai apa?”
FAQ singkat
Apakah semua aplikasi perlu elastic caching?
Nggak. Banyak aplikasi cukup dengan TTL, LRU/LFU, dan metric yang rapi. Elastic caching lebih relevan saat biaya memori dan cache miss sama-sama signifikan.
Apakah Redis masih pilihan bagus?
Masih, kalau problem-nya cocok. Redis punya eviction policy yang matang dan ekosistem luas. Tapi Redis bukan pengganti desain data, observability, dan cost review.
Metric cache apa yang wajib dipantau?
Minimal: hit rate, miss rate, eviction count, memory usage, latency backend saat miss, ukuran keyspace, dan biaya layanan cache.
