Strategi In-Memory Caching: Mengoptimalkan Database Input Output Dengan Redis Architecture

Hukum fisik utama dalam arsitektur komputer menyatakan bahwa membaca data dari memori utama (RAM) berkecepatan orde nanosekon, sedangkan membaca data dari media penyimpanan disk (SSD atau Hard Disk) berkecepatan orde milidetik. Perbedaan kecepatan ini mencapai rentang hingga 10.000 kali lipat.

Dalam aplikasi web berkinerja tinggi yang menangani ribuan permintaan concurrent per detik, melakukan kueri langsung ke database utama (seperti PostgreSQL atau MySQL) untuk setiap permintaan pengguna adalah penyebab paling tajam dari penurunan performa. Di sinilah arsitektur Redis In-Memory Caching berperan sebagai akselerator utama.

Pola-Pola Utama In-Memory Caching (Caching Patterns)

Pemilihan pola interaksi antara aplikasi, cache Redis, dan database utama menentukan tingkat performa dan konsistensi data yang dihasilkan. Terdapat beberapa arsitektur caching standar:

• Cache-Aside (Lazy Loading): Aplikasi memeriksa cache terlebih dahulu. Jika data ditemukan (Cache Hit), data langsung dikembalikan. Jika tidak (Cache Miss), aplikasi membaca dari database, menyimpannya di Redis, lalu mengembalikannya. Pola ini paling populer karena fleksibilitasnya.
• Write-Through: Data ditulis ke Redis dan database utama secara bersamaan. Menjamin data di cache selalu segar, namun menambahkan latensi pada operasi penulisan.
• Write-Behind (Write-Back): Data ditulis ke Redis terlebih dahulu dan langsung merespons pengguna. Penulisan ke database utama dilakukan secara asinkron di latar belakang. Sangat cepat, namun memiliki risiko kehilangan data jika Redis mengalami crash sebelum sinkronisasi.

"Hanya ada dua hal yang sangat sulit dalam computer science: Naming Things dan Cache Invalidation. Merancang strategi invalidasi yang tepat adalah kunci menjaga konsistensi tanpa mengorbankan kecepatan."

MAYASTRA NAWALOKA - System Performance Architecture

Implementasi Cache-Aside Pattern & TTL Management

Berikut adalah contoh implementasi Cache-Aside Pattern yang aman dengan menyertakan durasi masa berlaku (Time To Live / TTL) untuk mencegah stleness data:

import Redis from 'ioredis';
import { db } from './database';

const redis = new Redis(process.env.REDIS_URL);
const DEFAULT_CACHE_TTL_SECONDS = 300; // 5 Menit TTL

export async function getProductCatalog(categoryId: string) {
    const cacheKey = `catalog:category:${categoryId}`;

    try {
        // 1. Coba ambil dari Redis In-Memory Cache
        const cachedData = await redis.get(cacheKey);

        if (cachedData) {
            // Cache Hit: Kembalikan data instan dalam hitungan <5ms
            return JSON.parse(cachedData);
        }

        // 2. Cache Miss: Ambil data dari Database Utama (I/O Disk)
        const catalogData = await db.query(
            'SELECT id, name, price, stock FROM products WHERE category_id = $1 AND is_active = true',
            [categoryId]
        );

        // 3. Simpan data ke Redis dengan TTL (Expirable Cache)
        if (catalogData.rows.length > 0) {
            await redis.setex(
                cacheKey,
                DEFAULT_CACHE_TTL_SECONDS,
                JSON.stringify(catalogData.rows)
            );
        }

        return catalogData.rows;
    } catch (error) {
        // Fallback: Jika Redis mengalami kendala jaringan, query tetap berjalan langsung ke DB
        console.error('Redis Cache Failover:', error);
        const fallbackData = await db.query('SELECT * FROM products WHERE category_id = $1', [categoryId]);
        return fallbackData.rows;
    }
}

Mitigasi Fenomena Cache Stampede (Thundering Herd)

Salah satu bahaya terbesar pada aplikasi berskala besar adalah Cache Stampede. Hal ini terjadi ketika kunci cache berkategori populer (seperti data halaman depan marketplace) kadaluarsa secara bersamaan. Ribuan kueri serentak mendadak menembus ke database utama secara simultan, menyebabkan server database kewalahan dan crash.

Strategi pencegahan Cache Stampede yang efektif meliputi:

Memilih Memory Eviction Policy Yang Tepat

Ketika kapasitas RAM yang dialokasikan untuk Redis mencapai batas maksimum, Redis akan menjalankan strategi eviksi (eviction policy) untuk menghapus data lama demi memberikan ruang bagi data baru:

1. volatile-lru (Least Recently Used): Menghapus kunci yang paling jarang diakses dan memiliki batas waktu TTL. Pilihan paling aman untuk gabungan cache dan session store.
2. allkeys-lru: Menghapus kunci apa pun yang paling jarang diakses tanpa mempedulikan status TTL. Sangat cocok jika Redis murni digunakan sebagai caching layer.
3. volatile-lfu (Least Frequently Used): Menghapus kunci berdasarkan frekuensi total akses terendah. Efektif menghindari penghapusan data populer yang kebetulan belum diakses beberapa detik terakhir.

MAYASTRA NAWALOKA

Software Engineering & Architecture Editorial

Tim rekayasa perangkat lunak MAYASTRA NAWALOKA berfokus pada pembangunan aplikasi web berkinerja tinggi, arsitektur yang mudah dipelihara, dan solusi digital berskala enterprise untuk bisnis Indonesia.