Strategi Caching: Pemuatan Malas dan Tulis Langsung

Menempatkan cache di antara aplikasi dan basis data memerlukan strategi caching — seperangkat aturan yang menentukan kapan data dimasukkan ke cache, kapan data dibaca dari cache, dan kapan data dikeluarkan. Memilih strategi yang salah dapat menyebabkan data usang (cache mengembalikan Value yang sudah kedaluwarsa), cache miss dingin (cache kosong dan setiap permintaan mengakses basis data), atau cache stampede (banyak permintaan simultan untuk Key yang sama-sama tidak tersedia semuanya mengakses basis data secara bersamaan). Dua strategi dasar tersebut adalah pemuatan malas dan write-through.

Pemuatan malas (juga disebut cache-aside) adalah pola caching yang paling umum. Aplikasi memeriksa cache terlebih dahulu. Saat terjadi cache hit, data langsung dikembalikan dari cache — jalur cepat. Saat terjadi cache miss, aplikasi mengambil data dari basis data, menulis hasilnya ke cache dengan TTL, lalu mengembalikannya kepada pemanggil. Cache hanya diisi dengan data yang benar-benar diminta — itulah alasan pola ini disebut "malas". Permintaan berikutnya untuk Key yang sama akan menemukannya di cache.

Pemuatan malas memiliki tiga kelebihan utama: hanya data yang diminta yang di-cache — cache tidak dipenuhi data yang tidak pernah dibaca, sehingga memori digunakan secara efisien. Cache dingin tidak membuat aplikasi berhenti — saat terjadi cache miss, aplikasi menggunakan basis data sebagai cadangan, sehingga meskipun ElastiCache dimulai ulang atau sebuah node mengalami kegagalan, aplikasi tetap berfungsi (dengan latensi yang lebih tinggi). Cache selalu pada akhirnya konsisten dengan basis data karena data usang kedaluwarsa melalui TTL meskipun beberapa pembaruan terlewat.

Pemuatan malas memiliki tiga kekurangan utama: cache miss membutuhkan biaya besar — tiga operasi (pemeriksaan cache, pembacaan basis data, dan penulisan cache) dibandingkan satu operasi untuk cache hit, sehingga menyebabkan latensi lebih tinggi pada permintaan saat cache dingin. Data usang — setelah pembaruan basis data, cache masih menyajikan Value lama sampai TTL kedaluwarsa atau Key dibatalkan validasinya secara eksplisit (jendela inkonsistensi cache). Cache stampede — jika Key yang populer kedaluwarsa, banyak permintaan simultan mengalami cache miss dan mengakses basis data secara bersamaan, yang berpotensi membebani basis data secara berlebihan.

Dalam strategi write-through, setiap penulisan ke basis data juga ditulis ke cache secara bersamaan. Aplikasi menulis ke cache dan basis data sebagai bagian dari operasi yang sama (atau basis data memicu pembaruan cache). Karena itu, cache selalu sinkron dengan basis data — tidak ada jendela data usang. Write-through menjamin bahwa data di cache selalu terbaru, sehingga pembacaan berikutnya selalu menjadi cache hit untuk data yang baru saja ditulis.

Kelebihan write-through: data cache selalu terbaru — tidak ada data usang karena cache diperbarui pada setiap penulisan. Pembacaan selalu cepat — data populer yang sering ditulis selalu tersedia di cache. Tidak ada cache stampede saat membaca — karena data diisi terlebih dahulu sebelum dibaca, tidak ada cache miss dingin untuk data yang baru ditulis. Strategi ini ideal untuk beban kerja yang didominasi pembacaan dengan pembaruan yang sering, seperti katalog product, sistem harga, atau cache profil User.

Kekurangan write-through: penalti penulisan — setiap penulisan memerlukan dua operasi (basis data + cache), sehingga menambah latensi penulisan. Polusi cache — data di-cache meskipun tidak pernah dibaca lagi (ditulis sekali dan tidak pernah diminta), sehingga memboroskan memori cache. Mulai ulang cache berarti cache dingin — jika klaster cache dimulai ulang, semua data yang ditulis secara proaktif akan hilang dan cache harus diisi ulang melalui penulisan atau proses pemanasan cache. Gabungkan write-through dengan TTL untuk mencegah pertumbuhan tanpa batas data cache yang jarang dibaca.

Dalam praktiknya, banyak sistem produksi menggabungkan kedua strategi: gunakan write-through untuk data yang sering diperbarui dan sering dibaca (seperti sesi User atau harga saat ini), dan pemuatan malas untuk data yang jarang diperbarui tetapi sering dibaca (seperti deskripsi product atau isi artikel). Tetapkan TTL yang sesuai untuk keduanya: Key write-through mendapatkan TTL panjang karena datanya selalu terbaru; Key yang dimuat secara malas mendapatkan TTL lebih pendek untuk membatasi jendela data usang. Pendekatan Hybrid ini memaksimalkan rasio cache hit sekaligus meminimalkan data yang usang.

Time-To-Live (TTL) pada data yang di-cache mengendalikan durasi maksimum jendela data usang dan jejak memori cache. Rancang TTL berdasarkan: frekuensi pembaruan data (data sesi sering berubah → TTL pendek; konten statis jarang berubah → TTL panjang), toleransi terhadap data usang (harga finansial → sangat pendek; teks kiriman blog → berjam-jam atau berhari-hari), dan kapasitas memori cache (memori rendah → TTL lebih pendek agar data usang dikeluarkan lebih cepat). Selalu tetapkan TTL — jangan pernah menyimpan data tanpa masa kedaluwarsa, atau cache pada akhirnya akan dipenuhi data usang.

Selain hanya mengandalkan kedaluwarsa TTL, Anda dapat membatalkan validasi (menghapus) Key cache secara eksplisit ketika data dasarnya berubah. Ini sepenuhnya menghilangkan jendela data usang. Pola yang umum: penghapusan saat penulisan (hapus Key cache setelah setiap pembaruan basis data — pembacaan berikutnya mengisinya kembali melalui pemuatan malas), pembatalan validasi berbasis peristiwa (DynamoDB Streams atau pengambilan perubahan RDS memicu Lambda yang menghapus Key yang terdampak). Pembatalan validasi cache adalah salah satu masalah tersulit dalam sistem terdistribusi; semakin sederhana logika pembatalan validasi, semakin andal cache Anda.

Pola yang lebih jarang digunakan tetapi kuat adalah write-behind (write-back): aplikasi hanya menulis ke cache, lalu cache secara asinkron mengalirkan data ke basis data di Background. Pola ini menghasilkan penulisan yang sangat cepat (hanya di memori), tetapi berisiko kehilangan data jika cache gagal sebelum melakukan pengaliran. Write-behind sesuai untuk penulisan berfrekuensi tinggi dan bervolume besar ketika data dapat direkonstruksi atau kehilangan kecil masih dapat diterima — misalnya penghitung hit, peristiwa analitik, atau pembaruan skor permainan. ElastiCache tidak mendukung write-behind secara native; pola ini harus diterapkan pada lapisan aplikasi.

Uji pemahaman Anda tentang konsep AWS Solutions Architect (SAA-C03) dari pelajaran ini.

Dalam pelajaran ini Anda mempelajari bahwa pemuatan malas mengisi cache saat terjadi cache miss pada pembacaan dan menggunakan memori secara efisien, tetapi dapat menyajikan data usang sampai TTL kedaluwarsa; write-through memperbarui cache pada setiap penulisan sehingga tidak ada data usang, tetapi memboroskan memori untuk data yang tidak dibaca; dan pembatalan validasi eksplisit menghapus Key cache saat basis data diperbarui untuk menghilangkan jendela data usang. Selanjutnya, kita akan membahas penyimpanan sesi dan pola papan peringkat dengan ElastiCache.