Mengira Snapshot RDB Redis Sudah Cukup Jadi Backup Saat Stok Pindah ke Memori

Saat pengecekan dan pengurangan stok dipindah dari database relasional ke Redis, pertanyaan soal persistensi sering dijawab singkat: Redis kan sudah bikin snapshot RDB. Masalahnya, snapshot itu potret pada satu titik waktu. Semua pengurangan stok yang terjadi setelah snapshot terakhir hanya ada di memori sampai snapshot berikutnya selesai ditulis. Kalau node crash di antara dua snapshot, perubahan itu hilang, dan stok bisa kembali ke angka yang sudah tidak benar. Alasan pindah ke Redis biasanya masuk akal. Pola cek stok lalu update langsung di database relasional bikin banyak transaksi berebut lock di baris yang sama saat flash sale. Akibatnya muncul deadlock, koneksi menumpuk, dan connection pool habis. Menaikkan batas koneksi jarang menolong, seperti dibahas di Kenapa Menaikkan max_connections di MySQL Malah Bikin Server Down. Dengan Redis dan Lua script, pengecekan dan pengurangan stok jalan atomik dalam satu eksekusi di memori. Jika stok habis, permintaan langsung ditolak tanpa membebani backend. Bagian ini bagus. Yang sering terlewat adalah pertanyaan apa yang terjadi pada angka stok itu kalau Redis mati mendadak. Di bawah ini beberapa anggapan yang paling sering muncul, kenapa terasa benar, dan apa yang sebenarnya terjadi.

Mitos 1: snapshot RDB rutin sudah sama dengan backup

RDB adalah file snapshot (biasanya dump.rdb) yang berisi seluruh dataset pada satu titik waktu. Redis membuatnya lewat BGSAVE. Proses utama melakukan fork, lalu child process menulis isi memori ke disk sementara proses utama tetap melayani request. Kapan snapshot dibuat diatur oleh aturan save, formatnya kira-kira setiap sekian detik jika ada minimal sekian perubahan. Nilai default-nya berbeda antarversi dan antarpaket, jadi sebaiknya dicek langsung di instance kamu. Anggapan ini terasa benar karena di keseharian datanya memang selalu balik. Restart terkontrol lewat SHUTDOWN umumnya menyimpan snapshot dulu sebelum proses berhenti, jadi setelah restart semuanya terlihat utuh. Di support, pola ini sering muncul: tim yakin Redis aman karena sudah berkali-kali restart tanpa masalah. Padahal yang diuji baru restart rapi, bukan crash. Kalau yang terjadi kernel panic, node mati listrik, atau proses dibunuh OOM killer, tidak ada kesempatan menyimpan snapshot terakhir. Redis akan memuat RDB terakhir yang berhasil ditulis. Ambil contoh ilustrasi: snapshot terakhir lima menit lalu. Semua decrement stok selama lima menit itu hilang, dan stok yang dimuat ulang lebih tinggi dari kenyataan. Di sistem stok, ini berarti barang yang sudah terjual bisa terjual lagi. Ada dua hal lain yang perlu diperhatikan. Pertama, fork di instance bermemori besar butuh waktu dan memori tambahan karena copy-on-write. Kalau BGSAVE gagal, interval kehilangan datamu diam-diam jadi lebih panjang. Kedua, dengan stop-writes-on-bgsave-error aktif, Redis akan menolak write setelah snapshot gagal. Ini aman dari sisi data, tapi bisa terlihat seperti outage di tengah flash sale.

Mitos 2: begitu AOF aktif, tidak ada data yang hilang

AOF (Append Only File) bekerja berbeda. Setiap perintah yang mengubah data ditambahkan ke file log. Saat restart, Redis memutar ulang log itu untuk membangun kembali dataset. Secara konsep ini jauh lebih rapat daripada snapshot berkala, tapi seberapa rapat ditentukan oleh appendfsync. Yang perlu dipahami: menulis ke file belum berarti data sudah aman di disk. Data bisa masih di page cache kernel sampai fsync dipanggil. Opsi appendfsync mengatur kapan Redis memaksa fsync.

always: fsync dilakukan sebelum Redis membalas client. Kehilangan data paling kecil, tapi throughput bergantung pada kecepatan disk. Di disk lambat, ini terasa sekali.
everysec: fsync sekitar sekali per detik di background. Ini default yang umum dan kompromi yang paling sering dipakai. Kalau node crash, yang hilang biasanya sekitar satu detik terakhir, bisa sedikit lebih kalau disk sedang lambat.
no: Redis menyerahkan flush ke kernel. Jendela kehilangan data jadi tergantung perilaku writeback OS, dan biasanya lebih lebar dari satu detik.

Ada nuansa yang sering bikin bingung. Kalau yang crash hanya proses Redis sementara OS tetap hidup, data yang sudah ditulis ke AOF masih ada di page cache dan tetap akan sampai ke disk. Jadi everysec nyaris tidak kehilangan apa pun pada crash proses. Perbedaan antaropsi baru terasa kalau seluruh node mati, misalnya kernel panic, host virtualisasi down, atau listrik padam. Itulah skenario yang perlu dipakai saat menghitung RPO (Recovery Point Objective, yaitu berapa banyak data terakhir yang masih bisa diterima hilang). Satu jebakan saat mengaktifkan AOF di instance yang sudah berisi data: jangan langsung mengubah appendonly yes di file konfigurasi lalu restart. Di beberapa versi, Redis yang dikonfigurasi memakai AOF akan memuat dari AOF. Kalau file AOF belum ada, instance bisa naik dengan dataset kosong. Cara yang lebih aman adalah mengaktifkannya saat runtime dengan CONFIG SET appendonly yes, menunggu proses penulisan AOF awal selesai, baru menyimpan konfigurasinya. Cek dokumentasi versi yang kamu pakai, karena format AOF sendiri sudah berubah di Redis 7 menjadi beberapa file dalam satu direktori.

Mitos 3: replica dan Redis Cluster otomatis menutup celah ini

Anggapan ini muncul karena ada salinan data di node lain. Kalau master mati, replica naik jadi master, jadi seolah tidak ada yang hilang. Replikasi Redis bersifat asynchronous. Master membalas client dulu, baru mengirim perubahan ke replica. Dalam rentang singkat itu, sebuah decrement stok bisa sudah dikonfirmasi ke aplikasi tapi belum sampai ke replica. Saat failover, replica yang dipromosikan tidak punya perubahan tersebut. Ini berlaku juga di Redis Cluster, karena tiap shard memakai mekanisme replikasi yang sama. Perintah WAIT bisa membuat client menunggu sampai sejumlah replica menerima write. Celahnya jadi lebih kecil, tapi dokumentasi Redis sendiri menyebut ini tidak menjadikan Redis strongly consistent. Ada juga kombinasi yang berbahaya: master tanpa persistensi tapi diatur restart otomatis. Kalau master crash lalu cepat hidup lagi dengan dataset kosong, replica akan sinkron ke master tersebut dan ikut kosong. Jadi replikasi bukan pengganti persistensi. Keduanya menjawab masalah berbeda. Replikasi untuk ketersediaan, persistensi untuk pemulihan.

Mitos 4: kalau Redis sudah benar, database cukup dicatat belakangan

Di arsitektur memory-first, Redis memang jadi benteng utama untuk rate limiting, antrean, dan stok. Database relasional berperan sebagai ledger, yaitu pencatatan akhir yang tenang. Kata kuncinya ledger. Artinya database harus berisi catatan yang cukup untuk menghitung ulang kondisi stok, bukan sekadar salinan yang diisi kalau sempat. Kenapa ini penting? Dengan konfigurasi persistensi apa pun, selalu ada skenario di mana angka di Redis tidak bisa dipercaya penuh. Contohnya snapshot yang tertinggal, failover yang kehilangan write terakhir, atau bug di script. Saat itu terjadi, kamu butuh sumber lain untuk menjawab berapa stok yang benar. Secara umum, alurnya seperti ini:

Database menyimpan alokasi stok awal per item untuk event tersebut.
Setiap order yang sudah dikonfirmasi tercatat di database dengan ID unik.
Reservasi yang masih berjalan (misalnya menunggu pembayaran) juga punya jejak yang bisa dihitung, entah di database atau di event yang tersimpan di message queue.
Stok yang benar adalah alokasi awal dikurangi order terkonfirmasi dan reservasi aktif. Angka itu yang dipakai untuk membangun ulang counter di Redis.

Agar langkah terakhir bisa dipercaya, penulisan ke ledger harus idempotent. Retry dari worker atau replay event tidak boleh menghasilkan order ganda. Biasanya ini dijaga dengan ID reservasi unik dan constraint unik di database, bukan dengan logika di aplikasi saja. Job rekonsiliasi berkala yang membandingkan counter Redis dengan hasil hitung dari ledger juga membantu menangkap selisih sebelum jadi keluhan.

Yang perlu dicek sebelum flash sale

Langkah pertama yang masuk akal adalah melihat konfigurasi persistensi yang benar-benar aktif. Jangan berpatokan pada file konfigurasi yang mungkin sudah tidak sesuai. Perintah berikut hanya membaca. Sesuaikan host, port, dan autentikasi dengan setup kamu. Di Redis Cluster, cek setiap node satu per satu.

BASH

# Read-only: konfigurasi persistensi yang sedang berlaku
redis-cli CONFIG GET save
redis-cli CONFIG GET appendonly
redis-cli CONFIG GET appendfsync

# Status snapshot dan AOF terakhir
redis-cli INFO persistence

Dari output INFO persistence, perhatikan rdb_last_bgsave_status dan aof_last_write_status untuk memastikan tidak ada penulisan yang gagal. rdb_changes_since_last_save menunjukkan berapa perubahan yang belum masuk snapshot. aof_enabled menunjukkan apakah AOF benar-benar aktif. Di layanan Redis terkelola, perintah CONFIG sering dibatasi, jadi informasinya perlu dicari di dashboard atau dokumentasi penyedia. Pegangan praktisnya begini. Tentukan dulu berapa detik data stok yang boleh hilang, lalu pilih persistensi yang sesuai. Untuk counter stok, biasanya itu berarti AOF dengan everysec sebagai titik awal, RDB tetap jalan sebagai salinan cadangan, dan file keduanya disalin ke luar node. Setelah itu, pastikan database relasional menyimpan cukup informasi untuk membangun ulang angka di Redis kapan pun dibutuhkan, dan uji proses itu sekali sebelum event besar. Kalau prosedur rekonsiliasi belum pernah dijalankan, kita belum benar-benar tahu apakah stok bisa dipulihkan.