Belajar Redis - Caching Strategies & Design Patterns

#Pendahuluan

Tiga fase pertama series ini membekali kalian perintah dan struktur data Redis. Episode 11 mulai merangkainya menjadi pola arsitektur nyata: bagaimana Redis dipakai sebagai cache, pembatas laju request, pengunci terdistribusi, dan penyimpan session.

Ini adalah episode yang paling sering ditanya pada interview backend: kapan memakai Cache-Aside, bagaimana memilih eviction policy, dan bagaimana rate limiter yang benar bekerja. Kalian akan melihat bagaimana struktur data yang sudah dipelajari — Strings, Sorted Sets, Hashes — bersatu menjadi pattern yang solid.

#Caching Strategies

#Cache-Aside (Lazy Loading)

Strategi paling umum dan mudah dipahami. Aplikasi membaca cache dulu; jika miss, aplikasi membaca database, lalu menulis hasilnya ke cache:

GET data:1 → cache hit? → kembalikan
            → cache miss → query DB → SET data:1 value EX 300

Implementasi singkatnya di aplikasi: cek GET data:1, kalau nil berarti miss, ambil dari database, lalu SET data:1 value EX 300. Keunggulan Cache-Aside: sederhana, dan cache hanya berisi data yang benar-benar dibaca. Kelemahan: cache bisa basi sampai TTL kadaluarsa — istilahnya stale data.

#Write-Through dan Write-Behind

• Write-Through: setiap write ke database langsung juga ditulis ke cache secara sinkron. Keuntungannya cache selalu konsisten; kerugiannya ada latency ekstra di jalur write, dan data yang jarang dibaca tetap memenuhi cache.
• Write-Behind (Write-Back): aplikasi menulis ke cache dulu, lalu cache di-flush ke database secara asinkron. Sangat cepat untuk write-heavy, tapi ada risiko data hilang jika cache crash sebelum flush selesai.

#Read-Through

Cache sendiri yang mengambil data dari database saat miss (biasanya dengan library/library khusus). Konsumen aplikasi hanya berbicara ke cache, tidak ke database — tapi mengoperasikan lapisan ini lebih kompleks.

Untuk mayoritas aplikasi, Cache-Aside + TTL adalah pilihan awal yang paling masuk akal.

#Cache Eviction Policies

#Memahami maxmemory

Saat maxmemory tercapai, Redis harus memutuskan key mana yang di-buang. Kebijakan ini diatur maxmemory-policy:

redis-cli CONFIG GET maxmemory-policy

redis-cli CONFIG GET maxmemory-policy menampilkan kebijakan saat ini. Opsi yang perlu kalian kenali:

• allkeys-lru: buang key apa pun yang paling jarang dipakai (approximate LRU) — pilihan umum untuk cache murni.
• allkeys-lfu: buang key yang paling jarang diakses berdasarkan frekuensi — lebih baik untuk pola akses yang miring.
• volatile-lru: buang key ber-TTL yang paling jarang dipakai; key tanpa TTL dibiarkan.
• volatile-ttl: buang key ber-TTL yang paling dekat kadaluarsanya.
• noeviction: jangan buang apa pun; perintah write akan error OOM command not allowed when used memory > 'maxmemory'.

Untuk cache murni dengan pola akses panas, allkeys-lfu sering lebih unggul: data yang selalu dibaca bertahan, data dingin dibuang.

#Common Caching Patterns

#Rate Limiter dengan Sorted Set (Sliding Window)

Batasi request per user dengan sliding window yang akurat — Sorted Set menyimpan timestamp sebagai score, elemen lama dihapus, lalu hitung jumlah dalam jendela:

redis-cli ZREMRANGEBYSCORE rl:user:42 -inf 1700000000
redis-cli ZADD rl:user:42 1700000000 "req-1"
redis-cli ZCARD rl:user:42

Pola ini menghapus request yang lebih tua dari jendela (ZREMRANGEBYSCORE), menambahkan request baru (ZADD), lalu mengecek ZCARD apakah sudah melewati limit. Untuk keakuratan penuh tanpa race condition, bungkus logika ini dalam script Lua (episode 10) — itulah alasan rate limiter produksi selalu memakai Lua.

#Distributed Lock dengan Redlock

Ketika beberapa instance aplikasi harus memastikan hanya satu yang bekerja (misal satu penjadwal cron), gunakan distributed lock. Berbasis SET NX PX:

redis-cli SET lock:job "instance-1" NX PX 30000
redis-cli EVAL "if redis.call('GET', KEYS[1]) == ARGV[1] then return redis.call('DEL', KEYS[1]) else return 0 end" 1 lock:job "instance-1"

Baris pertama mengambil lock dengan SET ... NX PX 30000 — hanya berhasil jika belum ada, dan berlaku 30 detik. Baris kedua melepas lock hanya jika pemiliknya benar (via Lua) — mencegah menghapus lock milik instance lain. Redlock memperluas pola ini ke beberapa node Redis untuk toleransi yang lebih tinggi, dengan trade-off kompleksitas.

#Session Store dengan Hash + TTL

Pola yang sudah kalian lihat di episode 4, dirangkum di sini karena ini pattern inti aplikasi web:

redis-cli HSET session:9f3a userId 123 role "admin"
redis-cli EXPIRE session:9f3a 1800

HSET session:9f3a userId 123 role "admin" menyimpan session sebagai objek, EXPIRE memberi masa hidup 30 menit. Expired session otomatis dibersihkan Redis — aplikasi tidak perlu cron cleanup. Pola ini dipakai hampir semua framework web yang mengaktifkan session store Redis.

#Penutup

Episode 11 merangkai struktur data Redis menjadi pola produksi: strategi Cache-Aside, Write-Through, Write-Behind, dan Read-Through; kebijakan eviction seperti allkeys-lru dan allkeys-lfu; rate limiter berbasis Sorted Set; distributed lock Redlock; serta session store Hash + TTL.

Inti yang harus dibawa pulang:

• Cache-Aside adalah strategi default: cek cache, miss → baca DB → tulis cache dengan TTL.
• Write-Behind cepat tapi berisiko kehilangan data saat crash.
• allkeys-lfu unggul untuk pola akses panas; noeviction membuat write error saat penuh.
• Rate limiter sliding window dibangun dari Sorted Set + Lua untuk akurasi atomik.
• Distributed lock memakai SET key value NX PX; release harus divalidasi owner via Lua.
• Session store = Hash + TTL; expired dibersihkan otomatis oleh Redis.

Di episode 12 selanjutnya kita mulai fase high availability: Replication (Master-Replica) & Redis Sentinel. Kalian akan belajar replication asinkron dengan REPLICAOF, read scaling, lalu Redis Sentinel sebagai watchdog dengan automatic failover. Lanjut!