TTL: apa itu, waktu hidup cache dan cara kerjanya

Apa itu TTL?

TTL (Time To Live) — adalah penanda waktu atau interval setelah itu data dianggap tidak valid. Dalam konteks caching, TTL menentukan berapa lama suatu catatan dapat disimpan dalam cache sebelum perlu diminta ulang dari sumber aslinya. Dalam protokol jaringan, TTL membatasi masa pakai paket, mencegah perutean tak terbatas.

Nilai TTL selalu dinyatakan dalam satuan waktu: milidetik, detik, menit, atau jam. Setelah waktu yang ditentukan kedaluwarsa, catatan akan dihapus dari cache atau ditandai sebagai stale (basi). Pada permintaan berikutnya ke catatan basi, sistem dapat mengembalikan data basi dengan pembaruan selanjutnya (stale-while-revalidate) atau memblokir permintaan hingga data segar diterima.

Pemilihan TTL selalu merupakan kompromi antara ketepatan waktu data dan kinerja. TTL yang terlalu pendek (1-5 detik) memaksa aplikasi untuk sering melakukan permintaan jaringan, menghilangkan manfaat caching. TTL yang terlalu panjang (jam/hari) meningkatkan risiko menampilkan informasi usang kepada pengguna. Nilai optimal tergantung pada jenis data: nilai tukar — detik, cuaca — menit, versi API — jam.

TTL dan invalidasi cache

TTL adalah invalidasi pasif: data secara otomatis dihapus setelah waktu kedaluwarsa. Alternatifnya adalah invalidasi aktif, di mana sumber data memberi tahu cache tentang perubahan (misalnya, melalui pesan WebSocket atau notifikasi push). Invalidasi pasif melalui TTL lebih sederhana dalam implementasi, tetapi tidak menjamin ketepatan waktu segera. Invalidasi aktif lebih kompleks, tetapi memungkinkan data tetap dalam keadaan terkini tanpa penundaan yang menjadi ciri khas TTL.

Bagaimana TTL bekerja

Mekanisme TTL dapat diimplementasikan dengan dua cara: kedaluwarsa absolut (absolute expiration) dan kedaluwarsa relatif (relative expiration). Pada kedaluwarsa absolut, catatan menyimpan waktu tertentu kapan akan menjadi tidak valid. Pada kedaluwarsa relatif — waktu pembuatan catatan dan TTL sebagai interval dicatat, dan pemeriksaan dilakukan dengan menghitung creationTime + TTL > currentTime.

Pada setiap permintaan ke cache, sistem memeriksa TTL setiap catatan. Jika TTL telah kedaluwarsa, data dihapus atau ditandai sebagai stale, dan permintaan diarahkan ke sumber. Untuk mengoptimalkan pemeriksaan TTL, dapat digunakan scheduled-cleanup (penghapusan periodik semua catatan yang kedaluwarsa) atau lazy-cleanup (penghapusan hanya saat mengakses catatan). Lazy-cleanup lebih efisien dalam hal memori karena tidak memerlukan thread latar belakang untuk memindai seluruh cache.

Dalam sistem terdistribusi, TTL juga digunakan untuk resolusi konflik otomatis. Misalnya, jika dua server secara bersamaan menulis nilai berbeda untuk kunci yang sama, catatan dengan TTL yang lebih lambat dapat dianggap prioritas. Amazon DynamoDB menggunakan TTL untuk menghapus otomatis catatan usang dalam tabel — ini adalah fungsi bawaan yang tidak memerlukan pengelolaan manual.

Strategi pembacaan data basi

Untuk meningkatkan kinerja setelah TTL kedaluwarsa, diterapkan strategi pembacaan data basi. Stale-while-revalidate — segera kembalikan data basi ke klien dan secara bersamaan jalankan pembaruan latar belakang. Stale-if-error — kembalikan data basi jika sumber untuk sementara tidak tersedia. Cache-Aside (Lazy Loading) — saat cache tidak ditemukan, muat data dari sumber, simpan dalam cache dengan TTL baru, dan baru kemudian kembalikan ke klien. Setiap strategi dipilih berdasarkan persyaratan konsistensi data.

TTL dalam caching data

Dalam aplikasi seluler, TTL adalah mekanisme kunci manajemen cache. Mari kita lihat skenario utama di mana TTL menentukan perilaku aplikasi dan pengalaman pengguna.

Caching respons HTTP

Protokol HTTP menyediakan mekanisme TTL bawaan melalui header Cache-Control. Arahan max-age mengatur TTL dalam detik: Cache-Control: public, max-age=3600 berarti respons dapat di-cache selama 1 jam. Arahan tambahan s-maxage (untuk cache bersama, misalnya CDN) dan stale-while-revalidate memberikan kontrol yang lebih halus. Jika TTL bertepatan dengan header expires, max-age memiliki prioritas sebagai standar HTTP/1.1 yang lebih modern.

Caching gambar

Untuk gambar, TTL dapat mencapai beberapa hari, karena konten jarang berubah. Namun, aplikasi seluler sering menggunakan pendekatan hibrida: TTL pendek untuk pratinjau (30 menit — ketepatan waktu bingkai) dan TTL panjang untuk gambar ukuran penuh (7 hari). Gambar dengan header HTTP Cache-Control: immutable tidak boleh diminta ulang sama sekali hingga TTL kedaluwarsa — ini adalah optimalisasi untuk sumber daya statis yang diusulkan dalam RFC 8246. Gambar-gambar tersebut di-cache di tingkat sistem operasi (URLCache, OkHttp Cache) tanpa keterlibatan aplikasi.

TTL dalam protokol jaringan

Dalam jaringan, TTL digunakan bukan untuk caching, tetapi untuk membatasi masa pakai paket. Setiap paket IP berisi bidang TTL (8 bit) yang dikurangi 1 oleh setiap router. Ketika TTL mencapai 0, paket dibuang, dan pesan ICMP Time Exceeded dikembalikan ke pengirim. Ini mencegah perutean tak terbatas pada loop di jaringan.

TTL dalam DNS

Catatan DNS memiliki TTL yang menentukan berapa lama resolver (misalnya, cache DNS ISP) dapat menyimpan catatan tanpa bertanya ke server otoritatif. Nilai tipikal: 300 detik (5 menit) untuk catatan dengan perubahan sering, 86400 detik (24 jam) untuk domain stabil. Layanan CDN sering menetapkan TTL rendah (60-300 detik) untuk pengalihan lalu lintas cepat saat terjadi kegagalan, sementara domain statis dapat memiliki TTL hingga 7 hari. Saat migrasi server, disarankan untuk menurunkan TTL terlebih dahulu menjadi 60 detik (48 jam sebelum migrasi) agar perubahan menyebar dengan cepat.

TTL dalam sesi dan token

Dalam aplikasi seluler, TTL digunakan untuk mengelola sesi dan token akses. Token JWT (JSON Web Tokens) berisi bidang exp (waktu kedaluwarsa) yang merupakan waktu Unix absolut kedaluwarsa. Setelah kedaluwarsa, token penyegar (refresh token) digunakan untuk mendapatkan token akses baru tanpa autentikasi ulang. TTL token akses biasanya 1-24 jam, TTL token penyegar 7-30 hari. Ini adalah keseimbangan antara keamanan (TTL pendek mengurangi risiko kebocoran) dan pengalaman pengguna (TTL panjang mengurangi frekuensi login ulang).

Strategi pemilihan TTL

Pemilihan TTL adalah keputusan teknik yang tergantung pada jenis data, SLA ketepatan waktu, dan biaya permintaan ulang. Mari kita lihat strategi utama.

TTL tetap

Pendekatan paling sederhana — semua catatan memiliki TTL yang sama. Misalnya, menyimpan cache semua respons API selama 5 menit. Keuntungan: kesederhanaan implementasi dan perilaku yang dapat diprediksi. Kerugian: tidak memperhitungkan frekuensi perubahan yang berbeda dari berbagai jenis data. TTL tetap dibenarkan untuk data homogen di mana semua catatan memiliki ‛kesegaran“ yang sama — misalnya, nilai tukar kripto di satu bursa.

TTL adaptif

TTL berubah secara dinamis tergantung pada perilaku data. Misalnya, jika suatu catatan jarang diperbarui di server, TTL meningkat; jika sering diperbarui — menurun. Implementasi dapat menggunakan header respons HTTP: header Age (berapa detik respons telah berada di cache) dan header Date memungkinkan penghitungan sisa waktu hidup. TTL adaptif memberikan hit-ratio yang lebih baik, tetapi memerlukan logika tambahan di sisi klien.

TTL dengan kedaluwarsa probabilistik

Probabilistic Early Expiration (PEE) — teknik di mana TTL dipilih secara acak dalam rentang tertentu. Ini mencegah ‛efek kawanan“ (thundering herd), ketika banyak permintaan kedaluwarsa secara bersamaan dan semua klien secara bersamaan mengakses sumber. PEE sangat berguna untuk CDN dan cache dengan beban tinggi: alih-alih TTL tunggal 300 detik, nilai acak antara 240 dan 360 detik digunakan, yang mendistribusikan beban pada sumber secara merata.

Contoh kode TTL

Mari kita lihat implementasi cache dengan TTL di Kotlin menggunakan kedaluwarsa absolut. Setiap catatan menyimpan waktu pembuatan, dan saat membaca diperiksa apakah TTL telah kedaluwarsa.

class TtlCache<K, V>(
    private val defaultTtlMs: Long = 300000L
) {
    private data class Entry<V>(
        val value: V,
        val createdAt: Long = System.currentTimeMillis()
    )

    private val map = ConcurrentHashMap<K, Entry<V>>()

    fun get(key: K): V? {
        val entry = map[key] ?: return null
        if (isExpired(entry)) {
            map.remove(key)
            return null
        }
        return entry.value
    }

    fun put(key: K, value: V, ttlMs: Long = defaultTtlMs) {
        map[key] = Entry(value, createdAt = System.currentTimeMillis() + ttlMs)
    }

    private fun isExpired(entry: Entry<*>): Boolean {
        return System.currentTimeMillis() > entry.createdAt
    }

    fun cleanup() {
        map.entries.removeIf { isExpired(it.value) }
    }
}

Kelas Entry menyimpan nilai dan waktu pembuatan + TTL (kedaluwarsa absolut). Metode get memeriksa kedaluwarsa pada setiap akses (lazy-cleanup) — catatan yang kedaluwarsa hanya dihapus saat ada upaya mengaksesnya. Metode cleanup dapat dipanggil secara periodik dari thread latar belakang untuk menghapus semua catatan usang secara batch. ConcurrentHashMap memastikan keamanan thread tanpa memblokir seluruh cache.

Contoh: TTL untuk caching respons API di iOS

Di iOS, untuk caching dengan TTL, mudah menggunakan URLCache dengan pengaturan memoryCapacity dan diskCapacity. Namun, URLCache tidak mendukung TTL individual untuk permintaan yang berbeda. Mari kita lihat wrapper kustom NSCache dengan dukungan TTL.

final class ApiResponseCache {
    private var cache = NSCache<NSString, CacheEntry>()

    func getResponse(for url: URL) -> Data? {
        guard let entry = cache.object(forKey: url.absoluteString as NSString)
            else { return nil }
        guard entry.expirationDate > Date() else {
            cache.removeObject(forKey: url.absoluteString as NSString)
            return nil
        }
        return entry.data
    }

    func storeResponse(data: Data, for url: URL, ttl: TimeInterval) {
        let entry = CacheEntry(data: data, expirationDate: Date().addingTimeInterval(ttl))
        cache.setObject(entry, forKey: url.absoluteString as NSString)
    }
}

final class CacheEntry: NSObject {
    let data: Data
    let expirationDate: Date
}

Dalam implementasi ini, NSCache digunakan sebagai penyimpanan yang aman untuk thread. CacheEntry berisi Data dan expirationDate. Saat get, diperiksa apakah waktu telah kedaluwarsa; jika ya — catatan dihapus dan nil dikembalikan. TTL diatur dalam detik melalui TimeInterval dan dapat berbeda untuk setiap URL: nilai tipikal untuk respons API adalah 120 detik untuk konten dinamis dan 3600 untuk data statis.