Redis untuk Backend: Cache, Session, dan Pub/Sub

Redis sering diperkenalkan sebagai “cache yang cepat”. Itu memang benar, tapi bukan hanya itu. Redis adalah data store in-memory dengan beberapa struktur data, optional persistence, expiration control, dan replication. Ia bisa mengurangi beban database, menyimpan session, mengoordinasikan pekerjaan singkat, serta menyebarkan notifikasi real-time. Setiap use case punya konsekuensi saat gagal, jadi jangan memperlakukan Redis seperti wadah data umum.

Kapan Redis tepat dipakai?

Redis paling berguna ketika data sering dibaca, bisa dibangun kembali, atau memang berumur pendek: halaman produk, lookup permission, counter rate limit, session, dan status presence di chat. Jangan menjadikannya source of truth tanpa rencana untuk order, saldo, atau data yang tidak boleh hilang. Simpan record bisnis yang tahan lama di database utama, lalu gunakan Redis agar read dan koordinasi menjadi lebih murah.

Pola cache yang aman di production

Pola umum adalah cache-aside: aplikasi mengecek Redis, membaca database jika miss, lalu menyimpan hasil dengan expiry.

const key = `product:${productId}`;
const cached = await redis.get(key);

if (cached) return JSON.parse(cached);

const product = await db.product.findById(productId);
await redis.set(key, JSON.stringify(product), { EX: 300 });
return product;

TTL bukan tambahan opsional. Tanpanya, nilai lama menumpuk selamanya. Tentukan TTL dari tingkat stale data yang masih dapat diterima, lalu invalidasi saat write bila pengguna harus langsung melihat perubahan. Menghapus product:42 setelah produk diedit biasanya lebih sederhana daripada memperbarui semua bentuk cache.

Waspadai cache stampede: saat key populer habis masa berlakunya, banyak request dapat membangun ulang data bersamaan. Tambahkan jitter pada TTL, pakai lock singkat untuk rebuild mahal, atau layani nilai sedikit stale ketika satu worker melakukan refresh. Cache hanya hasil yang aman; jangan membuat error sementara atau kegagalan authorization bertahan lebih lama dari yang seharusnya.

Session dan authentication

Redis cocok untuk session store ketika instance aplikasi stateless. Simpan session ID yang opaque dalam cookie secure dan HTTP-only, lalu simpan dokumen session server-side di Redis dengan TTL sesuai kebijakan session.

Jaga session tetap kecil: user ID, session version, waktu dibuat, dan claim yang memang dibutuhkan tiap request. Jangan masukkan password, access token, atau profile besar. Rotasi session ID setelah login dan perubahan privilege, aktifkan Secure, HttpOnly, serta SameSite yang tepat, dan hapus key Redis saat logout. Untuk logout semua perangkat, pakai session version atau daftar session aktif; jangan scan seluruh keyspace.

Pub/Sub bukan queue yang durable

Redis Pub/Sub mengirim pesan ke subscriber yang sedang tersambung. Ia cocok untuk event “refresh layar ini”, fan-out WebSocket lokal, atau hint invalidasi cache. Subscriber yang terputus akan melewatkan pesan dan tidak ada backlog yang tahan lama.

Untuk pekerjaan yang wajib selesai—kirim email, rekonsiliasi pembayaran, konversi gambar—gunakan queue atau stream durable yang punya acknowledgement, retry, dead-letter handling, dan consumer idempotent. Redis Streams dapat memberi consumer group serta pesan tersimpan, tetapi tetap membutuhkan operasi dan monitoring yang jelas.

Memory, eviction, dan persistence

Redis menyimpan working set di memory. Konfigurasikan maxmemory dan eviction policy secara sengaja. allkeys-lru masuk akal untuk cache murni; noeviction lebih aman untuk workflow penting karena write akan gagal secara terlihat daripada membuang key diam-diam. Jangan mencampur queue penting dengan data cache yang boleh dibuang dalam instance sama tanpa memahami konsekuensinya.

RDB snapshot memberi persistence point-in-time yang ringkas. AOF mencatat operasi write dan dapat mengurangi kehilangan data di antara snapshot dengan biaya I/O lebih besar. Replication membantu availability, tetapi failover masih dapat kehilangan write terbaru tergantung konfigurasi. Uji restore dan failover; pengaturan backup bukan berarti recovery plan sudah siap.

Key, observability, dan keamanan

Gunakan key yang konsisten seperti app:session:<id> dan app:rate-limit:<userId>:<minute>. Hindari KEYS * di production karena dapat memblokir server pada keyspace besar; gunakan SCAN untuk maintenance. Pantau penggunaan memory, hit rate, eviction, command latency, client terhubung, replication lag, dan write yang ditolak. Untuk workload stateful, eviction wajib menjadi alert.

Perlakukan credential Redis seperti credential database, gunakan TLS jika traffic melewati network boundary yang tidak sepenuhnya tepercaya, dan batasi akses jaringan. Redis yang terbuka ke internet dapat berubah menjadi insiden kehilangan data.

Checklist praktis

• Tentukan apakah setiap key adalah cache, session, state koordinasi, atau pekerjaan durable.
• Beri TTL, aturan invalidasi, dan owner untuk setiap key non-durable.
• Uji cache miss, stampede, eviction, restart, dan Redis tidak tersedia.
• Buat consumer idempotent dan pilih mekanisme durable untuk pekerjaan yang wajib terkirim.
• Pantau memory, eviction, latency, dan hit rate sebelum service berada di bawah tekanan.

Kesimpulan

Redis memberi hasil terbaik saat dipakai secara presisi. Gunakan sebagai lapisan percepatan dan alat koordinasi berumur pendek, dengan expiry serta perilaku gagal yang jelas. Ketika data modelnya sesuai masalah, Redis membuat sistem lebih cepat dan sederhana; ketika ia dijadikan primary database tanpa rencana, kegagalan akan jauh lebih sulit dipahami.