Caching Tidak Selalu Membuat Aplikasi Lebih Cepat

Gue dulu menganggap cache sebagai tombol turbo. Query lambat? Tambah Redis. Endpoint ramai? Cache response. Beberapa menit kemudian dashboard memang terasa cepat, sampai ada pengguna yang melihat data lama dan tim mulai bertanya: “Angka ini sebenarnya benar atau cuma cepat?”

Caching bukan akselerator otomatis. Cache hanya memindahkan pekerjaan: data disalin ke tempat yang lebih dekat, lalu aplikasi berharap salinan itu masih layak dipercaya.

Cache hit bukan satu-satunya ukuran

Cache hit rate 95% terdengar hebat. Tapi kalau lima persen cache miss berisi query terberat dan datang bersamaan, database tetap bisa tersedak. Ada juga biaya serialisasi, koneksi Redis, network hop, dan waktu untuk mengisi cache kembali.

Sebelum menambah cache, ukur dulu:

• endpoint mana yang benar-benar lambat;
• apakah bottleneck ada di query, jaringan, atau render;
• berapa lama data boleh stale;
• apa yang harus terjadi setelah data berubah.

Kalau query 20 ms dan cache membutuhkan 15 ms plus kompleksitas invalidasi, cache bukan optimasi. Itu utang teknis dengan nama yang lebih keren.

Invalidasi adalah bagian tersulit

set(key, value, 60) mudah. Pertanyaan sulitnya: kapan key dihapus ketika user mengubah profil, artikel dipublish, atau harga berubah?

Cache yang tidak pernah invalid bisa membuat pengguna mengambil keputusan dari data yang salah. Cache yang terlalu agresif dihapus berubah menjadi database kedua yang tidak pernah mendapat kesempatan bekerja.

Untuk data yang boleh terlambat, TTL sederhana cukup. Untuk data penting, gunakan invalidasi berbasis event dan beri versi pada key. Jangan menyamarkan ketidakpastian dengan TTL yang panjang.

Waspadai cache stampede

Ketika key populer kedaluwarsa, banyak request bisa sekaligus menuju database. Gunakan stale-while-revalidate, lock singkat saat pengisian, atau jitter pada TTL agar semua key tidak mati bersamaan.

Kesimpulan gue sederhana: cache bukan bukti sistem sudah cepat. Cache adalah keputusan konsistensi. Pakai ketika angka dan kebutuhan stale-nya sudah jelas—bukan karena semua orang bilang Redis itu wajib.

---

Kapan cache justru memperlambat

Ada tiga pola yang sering gue temui. Pertama, cache dipasang di depan query yang sebenarnya lambat karena index-nya salah. Traffic kecil terlihat baik, tetapi ketika cache miss terjadi, semua request menunggu query yang sama. Perbaiki query dan ukur ulang sebelum menambah layer baru.

Kedua, cache dipakai untuk data yang harus konsisten. Contohnya saldo, status pembayaran, atau permission. Data seperti ini tidak boleh hanya mengandalkan TTL. Pengguna bisa melihat saldo lama tepat ketika transaksi sedang diproses. Untuk kasus tersebut, lebih baik cache hanya data yang tidak kritis, atau gunakan strategi read-after-write agar pembaca setelah perubahan melihat nilai terbaru.

Ketiga, key cache tidak punya ownership yang jelas. Satu service menulis key, service lain menghapusnya, dan tidak ada kontrak penamaan. Setelah beberapa bulan, tidak ada yang berani mengubah schema karena takut cache lama masih dibaca.

Gue biasanya mulai dari cache paling sederhana: HTTP cache untuk response publik, query yang sudah di-index, dan TTL pendek untuk data yang boleh stale. Setelah itu baru menilai apakah Redis memang dibutuhkan. Cache yang sedikit tetapi bisa dijelaskan lebih sehat daripada cache di semua tempat.

Checklist sebelum merge:

1. Apa sumber kebenaran datanya?
2. Berapa lama stale masih dapat diterima?
3. Siapa yang invalidasi key setelah write?
4. Apa yang terjadi saat cache mati?
5. Apakah ada metric hit, miss, latency, dan error?

Kalau cache mati membuat seluruh aplikasi mati, cache sudah berubah dari optimasi menjadi dependency. Pastikan origin tetap memiliki jalur aman, meski lebih lambat.

Sumber

• https://developer.mozilla.org/en-US/docs/Web/HTTP/Caching
• https://aws.amazon.com/caching/
• https://martinfowler.com/bliki/TwoHardThings.html