Cache Invalidation

Masalah Cache Invalidation

• Data di cache bisa menjadi tidak akurat saat data asli berubah
• Cache invalidation adalah proses menghapus atau memperbarui data usang
• Salah satu masalah tersulit dalam computer science

Strategi Cache Invalidation

TTL (Time-To-Live)

• Data otomatis dihapus setelah waktu tertentu
• Simplest strategy, tidak perlu logic tambahan
• Data bisa jadi stale hingga TTL habis

Explicit Invalidation

• Aplikasi menghapus cache saat data berubah
• Saat update database, aplikasi juga menghapus cache terkait
• Data di-cache selalu fresh setelah invalidation

Event-Driven Invalidation

• Sistem publish event saat data berubah
• Cache listener menerima event dan menghapus data yang relevan
• Cocok untuk arsitektur microservices

Write-Through Automatic Invalidation

• Saat write terjadi, cache otomatis diupdate
• Tidak perlu invalidation manual karena cache selalu sinkron

Pola Cache Invalidation

Key-Based Invalidation

• Cache key dibuat berdasarkan parameter query
• Saat data berubah, hapus cache dengan key yang sesuai
• Contoh: users:1 untuk user dengan ID 1

Tag-Based Invalidation

• Cache diberi tag berdasarkan resource
• Saat resource berubah, hapus semua cache dengan tag tersebut
• Contoh: semua cache dengan tag users dihapus saat user table berubah

Wildcard Invalidation

• Menghapus cache dengan pattern tertentu
• Contoh: menghapus semua cache yang key-nya dimulai dengan products:
• Berguna saat struktur cache kompleks

Cache Stampede (Thundering Herd)

• Banyak request masuk bersamaan saat cache expired
• Semua request mengakses database secara bersamaan
• Bisa membebani database hingga crash

Solusi Cache Stampede

• Lock: hanya satu request yang boleh ke database, lainnya menunggu
• Early Recompute: refresh cache sebelum TTL habis
• Probabilistic Early Expiration: kemungkinan refresh sebelum expired

Stale-While-Revalidate

• Cache mengembalikan data lama sambil mengupdate di background
• User tidak perlu menunggu cache refresh
• Data mungkin sedikit usang tapi response tetap cepat

Praktik Terbaik

• Gunakan TTL sebagai safety net meski menggunakan invalidation manual
• Beri nama cache key yang konsisten dan predictable
• Hapus cache saat data berubah, jangan update cache langsung
• Pantau cache hit ratio dan stale data incidents
• Gunakan distributed lock untuk mencegah cache stampede