Invalidasi Cache dalam Pengembangan Mobile: Strategi dan Mekanisme

Apa itu invalidasi cache?

Invalidasi cache — proses pembatalan atau pembaruan catatan yang di-cache yang tidak lagi sesuai dengan keadaan sumber data saat ini. Tidak seperti pembersihan manual seluruh cache, invalidasi bekerja secara tepat: hanya data yang keakuratannya dipertanyakan.

Cache menyimpan salinan data untuk akses cepat. Seiring waktu, data asli di basis data atau server dapat berubah — misalnya, pengguna memperbarui profil atau muncul postingan baru di feed. Jika cache tidak di-invalidasi, aplikasi akan menampilkan informasi usang, yang pada aplikasi mobile menyebabkan kesalahan transaksi, tampilan yang salah, dan hilangnya kepercayaan.

Kesulitan utama setiap invalidasi — pepatah terkenal “There are only two hard things in Computer Science: cache invalidation and naming things”. Kompleksitasnya terletak pada kenyataan bahwa cache tidak tahu kapan sumbernya berubah, jika tidak diberitahu secara eksplisit.

Menurut Martin Kleppmann, penulis buku „Designing Data-Intensive Applications” (O’Reilly, 2017), invalidasi yang benar memerlukan pemberitahuan perubahan terpusat atau mekanisme pemeriksaan keakuratan pada setiap pembacaan — kompromi antara kinerja dan konsistensi.

data class CacheEntryT(
    val data: T,
    val expiresAt: Long,
    val version: Int = 0
)

fun CacheT.isValid(key: String): Boolean =
    get(key)?.let { it.expiresAt > currentTimeMillis() && it.version == currentVersion(key) } ?: false

Kode ini menunjukkan pendekatan sederhana: catatan dalam cache dianggap valid jika TTL belum kedaluwarsa dan versi cocok dengan yang saat ini di sumber. Mekanisme versi — salah satu cara yang dapat diandalkan untuk menghindari menampilkan data usang.

Mengapa invalidasi diperlukan di aplikasi mobile

Keakuratan data — persyaratan utama untuk sebagian besar aplikasi mobile: jejaring sosial, messenger, layanan perbankan, platform e-commerce. Pengguna yang melihat saldo akun salah atau pesan lama kehilangan kepercayaan pada aplikasi.

Selain pengalaman pengguna, invalidasi memecahkan masalah penghematan lalu lintas dan baterai. Alih-alih memuat ulang data secara berkala, aplikasi mobile dapat meng-invalidasi hanya catatan yang berubah dan memuatnya secara tepat. Menurut Meta Engineering (2024), penerapan invalidasi inkremental di Facebook Lite mengurangi konsumsi lalu lintas sebesar 35% tanpa kehilangan keakuratan konten.

Aspek penting lainnya — konsistensi transaksi. Di aplikasi dengan keranjang belanja atau pemesanan, penggunaan cache usang dapat menyebabkan penggandaan biaya atau konflik data. Invalidasi setelah operasi kritis menjamin bahwa permintaan berikutnya akan membaca data terbaru.

Strategi utama invalidasi cache

TTL (Time-To-Live)

TTL — strategi paling sederhana, di mana setiap catatan dalam cache mendapatkan masa pakai tetap. Setelah TTL kedaluwarsa, data dianggap usang dan dihapus pada pembacaan berikutnya. TTL ideal untuk data yang diperbarui sesuai jadwal — misalnya, cuaca atau nilai tukar. Kekurangan: data mungkin tidak akurat dalam interval TTL.

Write-Through

Dalam strategi Write-Through, setiap perubahan data melewati cache: penulisan dilakukan secara bersamaan ke cache dan sumber. Ini menjamin bahwa cache selalu berisi versi terkini. Kekurangan — latensi penulisan meningkat, karena operasi tidak selesai hingga konfirmasi dari sumber. Write-Through cocok untuk data yang kritis terhadap konsistensi: saldo akun, status pesanan.

Write-Behind (Write-Back)

Write-Behind — penulisan asinkron: data segera masuk ke cache, dan ke sumber ditulis kemudian oleh proses terpisah. Ini memberikan kinerja penulisan tinggi, tetapi membawa risiko kehilangan data jika terjadi kegagalan sebelum sinkronisasi. Di aplikasi mobile, Write-Behind sering digunakan untuk analitik, log, dan tindakan pengguna yang tidak kritis.

Write-Invalidate

Write-Invalidate — alih-alih memperbarui cache saat data berubah, ia cukup menghapus (meng-invalidasi) catatan yang sesuai. Pembacaan berikutnya akan mendeteksi cache miss dan memuat data baru dari sumber. Strategi ini sederhana untuk diimplementasikan dan bekerja dengan baik ketika permintaan baca jauh lebih banyak daripada tulis.

Pemilihan strategi tergantung pada apa yang menjadi prioritas untuk skenario tertentu: kecepatan respons, konsistensi, atau penghematan sumber daya. Pendekatan hibrida — misalnya, TTL dengan Write-Invalidate saat menerima notifikasi push — memberikan keseimbangan optimal.

Bagaimana invalidasi bekerja di berbagai tingkat cache

Cache HTTP — tingkat pertama di sisi klien. Browser atau aplikasi mobile menyimpan respons server dengan header Cache-Control dan ETag. Invalidasi terjadi saat menerima respons 304 Not Modified atau setelah kedaluwarsa max-age. ETag memungkinkan klien memeriksa keakuratan sumber tanpa memuat respons lengkap.

Cache aplikasi — tingkat kedua, dikelola oleh kode: cache in-memory (LRU, LruCache di Android) atau disk (SQLite, Room, Realm). Invalidasi di sini dikendalikan oleh pengembang. Menurut Android Developers (2025), penggunaan Room yang benar dengan Flow dan invalidasi melalui pemicu mengurangi jumlah penggambaran ulang UI sebesar 40%.

Cache server — tingkat ketiga: Redis, Memcached, CDN. Pada tingkat ini, invalidasi dilakukan melalui TTL, perintah DEL/PURGE, atau broker pesan (RabbitMQ, Kafka). Invalidasi CDN — tugas terpisah: karena sifat CDN yang terdistribusi, perintah pembersihan dapat memakan waktu menit untuk menyebar. Menurut Cloudflare (2024), invalidasi melalui Purge by URL membutuhkan waktu rata-rata 5–15 detik untuk penyebaran global.

Untuk mengoordinasikan invalidasi di semua tingkat, digunakan layanan cache terpusat atau broker peristiwa. Saat data berubah, sumber memublikasikan peristiwa, dan setiap tingkat menerima perintah untuk meng-invalidasi kunci tertentu. Ini mencegah situasi di mana satu tingkat telah memperbarui data sementara yang lain terus memberikan versi usang.

Kesalahan umum dalam invalidasi cache

TTL terlalu panjang — kesalahan paling umum. Pengembang mengatur TTL “cadangan”, yang menyebabkan pengguna melihat data usang selama berjam-jam atau berhari-hari. Solusi: mulailah dengan TTL pendek (1–5 menit) dan tingkatkan hanya setelah mengukur kebutuhan sebenarnya.

Invalidasi seluruh cache untuk satu perubahan — masalah umum dalam arsitektur microservice. Satu pengguna memperbarui avatar, dan cache di-invalidasi untuk semua orang. Dengan jumlah pengguna yang besar, ini menyebabkan efek Cache Stampede — longsoran permintaan ke sumber. Solusi: invalidasi hanya kunci pengguna tertentu, bukan seluruh cache.

Tidak adanya invalidasi pada kesalahan penulisan — jika penulisan ke sumber gagal dan cache sudah diperbarui, aplikasi berada dalam keadaan tidak konsisten. Solusi: invalidasi dua fase — pertama bersihkan cache, lalu tulis ke sumber, dan batalkan invalidasi jika terjadi kesalahan.

Mengabaikan sifat terdistribusi — di lingkungan klaster, invalidasi pada satu node tidak berarti node lain telah menerima perintah. Tanpa broker peristiwa, sebagian server akan terus memberikan data usang. Redis Pub/Sub atau Apache Kafka memecahkan masalah ini dengan menyebarkan peristiwa invalidasi.

Cara memilih strategi invalidasi

Tentukan persyaratan keakuratan — seberapa kritis data harus segar “saat ini juga”. Untuk feed berita, keterlambatan 1–2 menit dapat diterima (TTL). Untuk saldo akun — keterlambatan tidak dapat diterima (Write-Through).

Evaluasi frekuensi perubahan — data yang diperbarui sekali sehari (katalog produk, direktori kota) bekerja sangat baik dengan TTL. Data yang berubah puluhan kali per detik (status online, nilai tukar) memerlukan invalidasi push melalui WebSocket atau Firebase Cloud Messaging.

Pertimbangkan biaya pembacaan sumber — jika sumbernya adalah kueri SQL mahal pada 10 tabel atau API eksternal dengan batasan, lebih baik menggunakan caching agresif dengan TTL panjang, tetapi mengompensasi data usang dengan invalidasi push. Jika pembacaan murah (in-memory lookup), TTL pendek dan Write-Invalidate dapat digunakan.

Menurut Google I/O (2025), pola umum untuk aplikasi mobile — Stale-While-Revalidate: pengguna langsung melihat data yang di-cache, dan aplikasi di latar belakang memeriksa keakuratannya dan memperbaruinya. Ini menggabungkan kecepatan respons dan keakuratan tanpa kompromi. Header HTTP Cache-Control dengan arahan stale-while-revalidate didukung mulai Android 10 dan iOS 13.