Belajar Redis - Studi Kasus Complete Production-Grade Redis Architecture

#Pendahuluan

Kita sudah di episode terakhir. Selama 19 episode kalian mempelajari perintah, struktur data, arsitektur, dan operasional Redis. Episode 20 ini adalah ujian dan hadiah sekaligus: merangkai semuanya menjadi satu arsitektur Redis production-grade yang lengkap untuk aplikasi web high-traffic.

Kita akan merancang arsitektur utuh — caching, session, rate limiting, real-time features, leaderboard — lalu menempatkannya di atas deployment 6-node cluster dengan TLS, ACL, dan monitoring. Akhiri dengan checklist kesiapan produksi dan refleksi perjalanan kalian.

#Arsitektur Kebutuhan Bisnis

#Skenario

Bayangkan sebuah platform e-commerce dengan: jutaan pengunjung harian, login session, API yang harus dilindungi dari abuse, order yang diproses real-time, dan fitur leaderboard produk terlaris. Kelima kebutuhan ini semua bisa ditangani satu Redis:

1. Caching layer          → Cache-Aside + TTL
2. Session management     → Hash + TTL 30 menit
3. Rate limiting          → Sorted Set sliding window + Lua
4. Real-time features     → Streams consumer groups + Pub/Sub
5. Leaderboard            → Sorted Sets

Perhatikan polanya: tiap peran memakai struktur data yang sudah kalian kuasai — Hashes, Sorted Sets, Streams, dan Strings. Redis menjadi tulang punggung tunggal untuk lima masalah berbeda.

#Merancang Setiap Lapisan

#Caching Layer: Cache-Aside + LFU

Semua response yang mahal di-cache dengan Cache-Aside (episode 11). Key diberi pola app:cache:* dan selalu punya TTL:

redis-cli SET app:cache:product:456 '{"name":"Laptop","price":1500}' EX 300

SET app:cache:product:456 '...' EX 300 — TTL 5 menit mencegah data basi dan memori membengkak. Dengan maxmemory-policy allkeys-lfu, produk paling laris bertahan di memori, produk dingin dibuang otomatis. Hit ratio di atas 0.95 menjadi target monitoring (episode 18).

#Session Management: Hash + TTL 30 Menit

Session login disimpan sebagai Hash dengan TTL 30 menit — expired dibersihkan otomatis:

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

EXPIRE session:9f3a 1800 memberi umur 30 menit. Pola dari episode 4 ini membuat logout otomatis, dan setiap aktivitas pengguna bisa memperpanjang TTL tanpa menulis ulang seluruh session.

#Rate Limiting: Sliding Window + Lua

API dilindungi rate limiter sliding window berbasis Sorted Set (episode 11), dibungkus Lua agar atomik (episode 10):

hapus request di luar jendela (ZREMRANGEBYSCORE)
tambah request baru (ZADD timestamp)
hitung jumlah dalam jendela (ZCARD)
tolak jika melebihi limit

Semua langkah dijalankan dalam satu script Lua sehingga tidak ada race condition — dua request bersamaan tidak bisa meloloskan batas. Script ini didaftarkan sebagai Redis Function agar reusable oleh semua service.

#Real-time Features: Streams + Pub/Sub

Order processing memakai Streams consumer groups: worker menambahkan event ke stream, consumer memprosesnya, dan XACK menjamin pengolahan tidak ganda:

redis-cli XADD orders '*' event "order.created" orderId "123"
redis-cli XREADGROUP GROUP orders_group worker-1 COUNT 10 STREAMS orders '>'

XADD orders '*' event "order.created" orderId "123" menulis event; XREADGROUP mengambilnya untuk diproses. Sementara itu, Pub/Sub membroadcast notifikasi real-time (misal ke WebSocket gateway) dengan PUBLISH order:123 "created" — yang bisa hilang tanpa masalah, berbeda dari event order yang wajib durable.

#Leaderboard: Sorted Sets

Produk terlaris dihitung real-time dengan Sorted Set — skor = jumlah terjual:

redis-cli ZINCRBY product:sales:2026 1 "product:456"
redis-cli ZREVRANGE product:sales:2026 0 9 WITHSCORES

ZINCRBY menambah penjualan secara atomik di setiap transaksi; ZREVRANGE 0 9 menampilkan top 10 — halaman "terlaris" tanpa query database.

#Deployment Architecture

#6-Node Redis Cluster + Hardening

Arsitektur deployment menggabungkan semua pelajaran high availability dan keamanan:

6 node: 3 master + 3 replica (redis cluster)
TLS aktif (tls-port 6380, sertifikat CA)
ACL: user default minimal, user app dengan scope key sendiri
maxmemory diatur + policy allkeys-lfu
protected-mode yes + bind hanya jaringan internal
Prometheus (redis_exporter) + Grafana dashboard & alert

Setiap master punya replica untuk failover otomatis (episode 13). TLS mengenkripsi semua lalu lintas (episode 14). ACL membatasi user app hanya pada pattern key miliknya — meski satu service diretas, blast radius dibatasi. Monitoring (episode 18) mengawasi memori, hit ratio, dan replication lag 24/7.

#Alur Data End-to-End

client → aplikasi → rate limiter (Lua + Sorted Set)
                     ├── cache hit? → kembali dari cache
                     ├── cache miss → DB → tulis cache TTL 300
                     ├── login → session Hash + TTL 1800
                     └── order → Streams consumer groups → XACK
                                  + PUBLISH ke WebSocket gateway

Setiap request lewat rate limiter lebih dulu, lalu dilayani dari cache bila memungkinkan. Write order dijamin oleh Streams, dan notifikasi real-time dikirim via Pub/Sub. Satu infrastruktur, lima masalah selesai.

#Checklist Kesiapan Produksi

#Yang Wajib Sebelum Go-Live

Sebelum mengumumkan produksi, pastikan semua poin ini tercentang:

• Semua key cache punya TTL; tidak ada key yang lupa expi
• maxmemory diatur, policy allkeys-lfu (atau sesuai workload)
• Replication sehat; tidak ada lag persisten (master_link_status:up)
• ACL aktif: user default minimal, user app ber-scope terbatas
• TLS aktif untuk semua koneksi internal dan eksternal
• FLUSHALL/FLUSHDB di-rename; KEYS tidak dipakai di kode
• Prometheus + Grafana terpasang, alert memori/hit ratio/lag aktif
• Backup RDB terjadwal ke storage eksternal
• Prosedur restore dan failover drill sudah diuji minimal sekali
• SLOWLOG dipantau; perintah berat diganti varian SCAN

#Maintenance Routine

Agar arsitektur tetap sehat: pantau metrik mingguan, review SLOWLOG bulanan, uji restore kuartalan, dan selalu upgrade ke versi Redis yang disarankan dengan rolling upgrade (episode 19).

#Penutup

Dan sampailah kita di akhir perjalanan. Episode 20 merangkai seluruh materi menjadi arsitektur Redis production-grade: caching layer dengan Cache-Aside dan LFU, session store Hash dengan TTL 30 menit, rate limiting sliding window berbasis Lua, real-time features dengan Streams consumer groups dan Pub/Sub, serta leaderboard Sorted Set — semuanya di atas 6-node cluster dengan TLS, ACL, dan monitoring Prometheus/Grafana.

Inti yang harus dibawa pulang:

• Satu Redis bisa menangani lima peran berbeda dengan struktur data yang tepat.
• Cache-Aside + TTL + allkeys-lfu menjaga memori dan hit ratio tetap sehat.
• Session = Hash + TTL 1800; expired dibersihkan otomatis.
• Rate limiter yang benar harus atomik — bungkus dalam Lua/Redis Functions.
• Order processing pakai Streams + XACK; notifikasi real-time pakai Pub/Sub.
• 6-node cluster + TLS + ACL + monitoring adalah kerangka produksi standar.
• Checklist kesiapan produksi wajib ditinjau dan diuji terus-menerus.

Perjalanan 21 episode ini membawa kalian dari redis-cli PING pertama sampai merancang arsitektur enterprise. Yang membedakan kalian sekarang dari pemula bukan hafalan perintah, tapi pemahaman mengapa dan kapan — dan itu modal paling berharga sebagai engineer. Terus bangun, terus uji, dan selamat berkarya dengan Redis!