Ini 4 cara arsitek sistem handle data REAL-TIME pakai Redis/Valkey. A Thread π§΅π
Strategi 1 - Write-Through (Hapus Pas Ada Data Baru)
Write-Through (Event-Driven)
Konsep: DB utama dan Cache di-update barengan.
Cara Kerja: Tiap ada transaksi/data baru masuk ke DB, aplikasi lo seketika langsung hapus atau update cache lama di Redis saat itu juga.
Cocok untuk: Data profil user, sisa saldo, atau status order yang harus akurat dalam hitungan milidetik.
Strategi 2 - Sorted Set (Redis Ikut Menghitung)
_Sorted Set / ZSET (Spesifik Leaderboard)
_
Konsep: DB simpan riwayat, Redis susun urutan.
Cara Kerja: Data mentah masuk ke DB (buat histori). Di saat bersamaan, skor dikirim ke fitur ZSET Redis. Redis bakal otomatis ngurutin posisi user secara in-memory dengan super cepat.
Cocok untuk: Leaderboard game, ranking penulis, atau produk terlaris secara real-time tanpa membebani query ORDER BY di SQL.
Strategi 3 - Near Real-Time (Kasih Napas 10 Detik)
Near Real-Time (TTL Pendek)
Konsep: Jujur aja, user gak butuh akurat sampai milidetik terakhir untuk data agregasi.
Cara Kerja: Data baru langsung ditulis ke DB. Tapi, cache di Redis sengaja dikasih umur (TTL) pendek, misal cuma 10-30 detik. Selama 10 detik itu, user baca dari cache.
Cocok untuk: Total penjualan toko, statistik pengunjung. Menghemat jutaan query ke DB saat traffic lagi tinggi (flash sale).
Strategi 4 - Write-Back (Tulis di Memori Dulu)
Write-Back / Write-Behind (Dewa Skalabilitas)
Konsep: Kebalikan dari nomor 1. Tulis di Redis dulu, DB belakangan.
Cara Kerja: Pas user klik sesuatu, angka langsung naik di Redis (instan). Nanti, setiap 5 atau 10 menit sekali, ada background job yang borong data dari Redis buat di-update massal (bulk) ke DB utama.
Cocok untuk: Sistem pencatat View Count YouTube atau tombol Like di Twitter/X.
Kesimpulan / Call to Action
Rangkuman Singkat:
β¨ Mau instan? Pakai Write-Through.
π Bikin ranking? Pakai ZSET.
π Data totalan/omset? Pakai TTL Pendek.
β€οΈ Fitur Like/Views massal? Pakai Write-Back.
Top comments (0)