Best Practice Cache Invalidation dan Warmup di CodeIgniter 4

Cache dapat meningkatkan performa aplikasi CodeIgniter 4 secara signifikan, tetapi cache juga memperkenalkan satu masalah klasik: cache invalidation. Menyimpan data agar respons lebih cepat itu mudah; menjaga agar data cache tetap konsisten dengan database jauh lebih sulit. Di aplikasi nyata, tantangannya bukan hanya kapan cache dibuat, tetapi juga kapan cache harus dihapus, diperbarui, atau dipanaskan ulang agar pengguna tidak menerima data usang.

Artikel ini membahas praktik terbaik untuk cache invalidation dan cache warmup di CodeIgniter 4 dengan pendekatan yang realistis. Fokusnya bukan sekadar memakai API cache, melainkan bagaimana merancang key yang aman, menghindari data stale, mengurangi cache stampede, dan menguji perilaku cache secara sistematis.

Memahami Tantangan Cache di CodeIgniter 4

CodeIgniter 4 menyediakan layanan cache melalui cache handler seperti file, Redis, Memcached, dan lainnya tergantung konfigurasi proyek. Secara umum, pemakaian dasarnya sederhana: simpan hasil query atau hasil komputasi ke cache, lalu ambil ulang bila tersedia. Masalah mulai muncul ketika data sumber berubah.

Contoh klasiknya adalah halaman daftar produk. Saat data produk diperbarui, cache daftar produk, detail produk, hasil pencarian, dan widget produk populer mungkin semuanya ikut terdampak. Jika hanya satu key yang dihapus, pengguna tetap bisa melihat data lama dari key lain yang belum diinvalidate.

Karena itu, cache yang baik harus didesain dengan mempertimbangkan:

Konsistensi: kapan data dianggap stale dan bagaimana cara memperbaruinya.
Granularitas: apakah cache disimpan per item, per daftar, atau per agregasi.
Isolasi: apakah cache aman untuk multi-tenant, per-user, atau per-locale.
Operasional: bagaimana warmup, monitoring, dan debugging dilakukan di produksi.

Prinsip penting: jangan mulai dari “apa yang bisa di-cache”, tetapi dari “data mana yang sering dibaca, jarang berubah, dan aman jika stale untuk beberapa detik atau menit”.

Desain Cache Key yang Aman dan Mudah Diinvalidasi

Struktur key yang konsisten

Kesalahan umum adalah membuat key cache terlalu sederhana, misalnya products atau user_profile. Key seperti ini berbahaya karena mudah bertabrakan antar konteks request. Gunakan pola key yang eksplisit.

tenant:{tenantId}:resource:product:list:page:{page}:sort:{sort}:lang:{locale}
tenant:{tenantId}:resource:product:detail:{productId}
user:{userId}:dashboard:summary
api:v1:tenant:{tenantId}:category:{categoryId}:top-products

Dengan format seperti ini, Anda mendapat beberapa keuntungan:

Mudah dilacak saat debugging.
Aman untuk multi-tenant karena ada pemisah tenantId.
Aman untuk cache per-user bila menyertakan userId.
Bisa diperluas untuk locale, versi API, atau variasi filter.

Hindari key yang kurang spesifik

Jika endpoint bergantung pada parameter query, sertakan parameter yang relevan ke key. Namun jangan sembarang menyisipkan seluruh query string mentah karena bisa membuat ledakan jumlah key. Pilih parameter yang memang memengaruhi hasil.

<?php

function buildProductListCacheKey(int $tenantId, array $filters): string
{
    $page   = $filters['page'] ?? 1;
    $sort   = $filters['sort'] ?? 'latest';
    $search = $filters['search'] ?? '';
    $locale = $filters['locale'] ?? 'id';

    return sprintf(
        'tenant:%d:product:list:page:%d:sort:%s:search:%s:lang:%s',
        $tenantId,
        $page,
        $sort,
        md5(trim(strtolower($search))),
        $locale
    );
}

Di sini, nilai pencarian di-hash agar key tetap pendek dan stabil.

Versi key untuk invalidasi massal

Salah satu teknik paling praktis adalah versioned key. Daripada menghapus semua key turunan satu per satu, simpan nomor versi untuk sebuah domain data, lalu gabungkan versi itu ke cache key.

tenant:{tenantId}:product:version = 42
tenant:{tenantId}:product:v42:list:page:1
tenant:{tenantId}:product:v42:detail:1001

Saat ada update besar, cukup naikkan versinya menjadi 43. Semua key lama otomatis tidak terpakai tanpa perlu disapu manual. Teknik ini sangat membantu bila backend cache tidak mendukung tag secara native.

Strategi Cache Invalidation yang Praktis

Invalidasi setelah operasi create/update/delete

Strategi minimum yang wajib diterapkan adalah invalidasi cache setelah operasi create, update, dan delete. Jangan mengandalkan TTL saja untuk data yang harus relatif segar.

Contoh service sederhana untuk produk:

<?php

namespace App\Services;

use Config\Services;

class ProductCacheService
{
    protected $cache;

    public function __construct()
    {
        $this->cache = cache();
    }

    public function getVersion(int $tenantId): int
    {
        $key = "tenant:{$tenantId}:product:version";
        return (int) ($this->cache->get($key) ?? 1);
    }

    public function bumpVersion(int $tenantId): void
    {
        $key = "tenant:{$tenantId}:product:version";
        $version = $this->getVersion($tenantId) + 1;
        $this->cache->save($key, $version, 86400 * 30);
    }

    public function detailKey(int $tenantId, int $productId): string
    {
        $version = $this->getVersion($tenantId);
        return "tenant:{$tenantId}:product:v{$version}:detail:{$productId}";
    }

    public function listKey(int $tenantId, array $filters): string
    {
        $version = $this->getVersion($tenantId);
        $page = $filters['page'] ?? 1;
        $sort = $filters['sort'] ?? 'latest';
        return "tenant:{$tenantId}:product:v{$version}:list:page:{$page}:sort:{$sort}";
    }
}

Lalu pada service bisnis atau controller yang menangani perubahan data:

<?php

$productModel->update($productId, $payload);
service('productCache')->bumpVersion($tenantId);

Pendekatan ini sederhana dan efektif. Trade-off-nya, semua cache terkait produk untuk tenant tersebut akan dianggap usang, termasuk yang sebenarnya tidak berubah. Untuk banyak aplikasi, itu masih jauh lebih baik daripada menyajikan data salah.

Invalidasi berbasis event

Untuk arsitektur yang lebih rapi, letakkan invalidasi cache di lapisan event atau service, bukan tersebar di controller. Tujuannya agar penghapusan cache tidak terlupa saat ada jalur update data baru, misalnya dari CLI command, job queue, atau admin panel.

Contoh konsepnya: setelah produk diperbarui, dispatch event domain seperti ProductUpdated, lalu listener akan menaikkan versi cache atau menghapus key tertentu. Jika aplikasi Anda belum memakai event yang formal, minimal buat service tunggal yang selalu dipanggil setelah write operation.

Keuntungan pendekatan berbasis event:

Logika invalidasi terpusat.
Lebih mudah diuji.
Mengurangi duplikasi di banyak endpoint.

Tag-based invalidation: kapan cocok dipakai

Beberapa sistem cache mendukung tag secara native, tetapi dukungannya bergantung pada handler. Karena itu, jangan menganggap semua driver di CodeIgniter 4 memiliki perilaku tag yang sama. Jika infrastruktur Anda memang mendukung tag, maka invalidasi menjadi lebih selektif: satu item bisa ditandai dengan beberapa tag seperti product, category:12, dan tenant:7.

Namun, untuk portabilitas dan kesederhanaan, banyak tim memilih versioned key atau index key sebagai pengganti tag. Misalnya, Anda menyimpan daftar key yang terkait dengan kategori tertentu lalu menghapus semuanya saat kategori berubah. Ini lebih merepotkan daripada tag native, tetapi lebih terkendali lintas driver.

TTL pendek vs TTL panjang

TTL adalah garis pertahanan terakhir, bukan mekanisme konsistensi utama. Memilih TTL yang tepat bergantung pada sifat datanya:

TTL pendek cocok untuk data yang sering berubah, misalnya ringkasan dashboard, stok, atau statistik near real-time.
TTL panjang cocok untuk data referensi yang jarang berubah, misalnya kategori, konfigurasi publik, atau konten statis hasil render.

Trade-off utamanya:

TTL pendek mengurangi risiko stale, tetapi meningkatkan beban cache miss.
TTL panjang meningkatkan hit rate, tetapi membuat invalidasi eksplisit semakin penting.

Praktik yang umum adalah menggabungkan TTL moderat + invalidasi eksplisit. Misalnya, detail produk disimpan 10 menit, tetapi juga diinvalidate segera setelah update.

Implementasi Helper atau Service Cache Khusus

Jangan menulis cache()->get() dan cache()->save() secara acak di seluruh codebase. Bungkus akses cache dalam helper atau service khusus agar pola key, TTL, logging, dan fallback konsisten.

<?php

namespace App\Services;

use App\Models\ProductModel;

class ProductReadService
{
    public function __construct(
        protected ProductModel $productModel,
        protected ProductCacheService $productCache
    ) {}

    public function getProductDetail(int $tenantId, int $productId): ?array
    {
        $key = $this->productCache->detailKey($tenantId, $productId);
        $cached = cache()->get($key);

        if ($cached !== null) {
            return $cached;
        }

        $product = $this->productModel
            ->where('tenant_id', $tenantId)
            ->find($productId);

        if (! $product) {
            return null;
        }

        cache()->save($key, $product, 600);
        return $product;
    }
}

Keuntungan pendekatan ini:

Pola akses data lebih mudah dibaca.
Logika fallback ke database terpusat.
Mudah menambah metrik hit/miss atau logging debug.
Mudah mengubah strategi cache tanpa menyentuh banyak file.

Cache Warmup untuk Endpoint Populer

Kapan warmup dibutuhkan

Cache warmup adalah proses mengisi cache sebelum ada lonjakan trafik atau segera setelah invalidasi massal. Ini berguna untuk endpoint populer seperti beranda, daftar produk unggulan, kategori utama, atau endpoint API yang sering dipanggil mobile app.

Tanpa warmup, invalidasi versi massal dapat menyebabkan banyak request pertama sama-sama menghantam database. Pada skala tertentu, ini bisa memicu lonjakan latensi.

Pendekatan warmup di CodeIgniter 4

Warmup paling aman dilakukan melalui command CLI, cron, atau worker terpisah, bukan memaksa pengguna pertama memuat ulang semuanya.

<?php

namespace App\Commands;

use CodeIgniter\CLI\BaseCommand;
use CodeIgniter\CLI\CLI;
use App\Services\ProductReadService;

class WarmupProductCache extends BaseCommand
{
    protected $group = 'Cache';
    protected $name = 'cache:warmup-products';
    protected $description = 'Preload cache untuk endpoint produk populer';

    public function run(array $params)
    {
        $service = service('productReadService');

        $popularTenantIds = [1, 2];
        $popularProductIds = [101, 102, 103, 104];

        foreach ($popularTenantIds as $tenantId) {
            foreach ($popularProductIds as $productId) {
                $service->getProductDetail($tenantId, $productId);
                CLI::write("Warmed tenant={$tenantId}, product={$productId}");
            }
        }
    }
}

Warmup yang baik memiliki karakteristik berikut:

Menargetkan endpoint atau key yang benar-benar sering diakses.
Dibatasi agar tidak membebani database.
Dapat dijalankan ulang dengan aman.
Dikombinasikan dengan observabilitas, misalnya log durasi dan jumlah key yang berhasil diisi.

Kesalahan umum adalah melakukan warmup terlalu agresif untuk semua kemungkinan kombinasi filter. Itu justru menghasilkan pemborosan memori dan beban backend.

Mitigasi Cache Stampede dan Soft Expiration

Masalah cache stampede

Cache stampede terjadi ketika banyak request datang bersamaan saat key yang sama tidak ada atau baru saja kedaluwarsa. Semua request lalu menghantam database secara paralel untuk membangun ulang cache yang sama.

Menggunakan locking sederhana

Solusi umum adalah lock singkat. Satu request mendapat hak membangun ulang cache, request lain menunggu sebentar atau memakai data stale bila masih tersedia.

Implementasinya bergantung pada backend cache. Dengan Redis, pola lock lebih andal karena mendukung operasi atomik. Pada driver file, lock lintas proses biasanya kurang ideal untuk trafik tinggi. Secara konsep:

<?php

$key = 'tenant:1:product:v42:detail:101';
$lockKey = $key . ':lock';
$data = cache()->get($key);

if ($data !== null) {
    return $data;
}

if (acquireLock($lockKey, 10)) {
    try {
        $data = $productModel->find(101);
        cache()->save($key, $data, 600);
        return $data;
    } finally {
        releaseLock($lockKey);
    }
}

usleep(200000);
return cache()->get($key);

Intinya bukan pada fungsi lock-nya, tetapi pada prinsip bahwa hanya satu request yang meregenerasi cache.

Soft expiration

Alternatif lain adalah soft expiration. Data tetap boleh disajikan untuk sementara walau sudah melewati ambang “sebaiknya direfresh”, lalu refresh dilakukan di belakang layar. Ini berguna untuk endpoint yang toleran terhadap stale beberapa detik.

Contohnya, simpan payload seperti:

{
  "data": {...},
  "fresh_until": 1710000000,
  "hard_expire_at": 1710000300
}

Jika waktu sekarang melewati fresh_until tetapi belum melewati hard_expire_at, aplikasi masih boleh mengembalikan data stale sambil memicu refresh asinkron. Dengan pendekatan ini, lonjakan load saat expiry bisa ditekan.

Trade-off soft expiration adalah kompleksitas lebih tinggi dan adanya jendela stale yang disengaja. Gunakan hanya untuk data yang memang tidak kritikal terhadap perubahan per detik.

Pengujian dan Debugging Perilaku Cache

Skenario yang perlu diuji

Cache sering terlihat benar saat diuji manual, tetapi gagal di kondisi nyata. Uji skenario berikut secara eksplisit:

Request pertama: memastikan data diambil dari database lalu disimpan ke cache.
Request kedua: memastikan data benar-benar berasal dari cache.
Setelah update data: memastikan key lama tidak dipakai lagi.
Setelah TTL habis: memastikan sistem membangun ulang cache dengan benar.
Concurrent request: memastikan tidak ada stampede berlebihan.
Multi-tenant/per-user: memastikan data tenant A tidak bocor ke tenant B.

Tambahkan logging hit/miss

Untuk debugging, logging sederhana sangat membantu. Misalnya log setiap hit, miss, dan invalidasi beserta key-nya. Di lingkungan non-produksi, ini membuat aliran cache jauh lebih mudah dianalisis.

<?php

log_message('debug', 'CACHE MISS: ' . $key);
log_message('debug', 'CACHE HIT: ' . $key);
log_message('info', 'CACHE INVALIDATE VERSION tenant=' . $tenantId);

Hindari mencatat payload besar atau data sensitif. Log cukup key, tenant, user context, dan event-nya.

Waspadai kesalahan umum

Menyimpan object yang sulit diserialisasi, terutama jika backend cache berbeda antara lokal dan produksi.
Melupakan konteks tenant/user di key sehingga terjadi kebocoran data.
Mengandalkan TTL tanpa invalidasi eksplisit untuk data yang sering berubah.
Menghapus terlalu banyak cache sehingga hit rate jatuh drastis.
Warmup semua kombinasi filter yang menyebabkan pemborosan memori.

Checklist Best Practice untuk Produksi

Gunakan key naming convention yang konsisten dan eksplisit.
Sertakan konteks tenant, user, locale, API version, atau filter penting ke cache key.
Gunakan versioned key untuk invalidasi massal yang sederhana dan andal.
Lakukan invalidasi segera setelah operasi create/update/delete, idealnya lewat service atau event terpusat.
Kombinasikan TTL yang masuk akal dengan invalidasi eksplisit; jangan bergantung pada TTL saja.
Bungkus akses cache dalam service/helper khusus agar pola konsisten dan mudah diuji.
Lakukan warmup hanya untuk key atau endpoint yang benar-benar populer.
Terapkan mitigasi cache stampede dengan locking, jitter TTL, atau soft expiration sesuai kebutuhan.
Tambahkan logging hit/miss dan invalidasi untuk mempermudah debugging.
Uji skenario multi-tenant, expired cache, concurrent access, dan fallback database sebelum deploy.
Pastikan backend cache yang dipilih sesuai beban aplikasi; file cache cukup untuk sederhana, tetapi Redis/Memcached lebih cocok untuk trafik lebih tinggi.

Pada akhirnya, cache yang efektif di CodeIgniter 4 bukan sekadar soal menyimpan data agar cepat, tetapi soal mengelola siklus hidup data cache dengan disiplin. Jika key dirancang dengan baik, invalidasi dipusatkan, warmup dilakukan selektif, dan stampede dimitigasi, Anda bisa mendapatkan performa tinggi tanpa mengorbankan konsistensi data secara berlebihan.

Quick Search

shopping_cart Keranjang