Belajar Floci - Storage Configuration (Memory, Hybrid, WAL, Persistent)

#Pendahuluan

Di episode 3 kalian sempat melihat keajaiban kecil: bucket S3 tetap ada setelah container restart. Itu bukan sihir — itu pilihan storage profile, dan pilihan ini justru salah satu keputusan operasional terpenting saat memakai Floci.

Mode yang tepat untuk unit test bisa sangat salah untuk dev environment yang berumur sehari penuh. Episode ini membahas empat mode, trade-off-nya, dan praktik benchmark agar kalian memilih berdasar data, bukan asumsi.

#Mode

#Empat Profil Storage

Mode	Mekanisme	Kecepatan	Bertahan Restart?	Cocok Untuk
memory	Semua state di RAM murni	Tertinggi	Tidak	Unit test, CI per-job
hybrid	RAM utama + checkpoint berkala	Tinggi	Sebagian (checkpoint)	Dev umum
WAL	Write-ahead log: tiap mutasi ditulis log dulu	Sedang	Ya (replay log)	Dev butuh durability ketat
persistent	Snapshot penuh + periodic async flush tiap 5 detik	Sedang–tinggi	Ya (hingga 5 detik data terakhir)	Dev environment jangka panjang

#Anatomi Tiap Mode

Memory — zero I/O disk; setiap PutItem hanya mutasi struktur di heap. Inilah alasan test suite berbasis floci bisa sangat cepat. Konsekuensinya tegas: container mati = semua hilang.

Hybrid — kompromi: operasi tetap di RAM, tapi snapshot periodik dituang ke disk (/app/data). Setelah crash, kembali ke checkpoint terakhir — tidak akurat 100%, tapi murah.

WAL (write-ahead log) — disiplin database sungguhan: sebelum mutasi diaplikasikan ke state, entri log ditulis dulu. Recovery = replay log dari awal/last checkpoint. Durability tertinggi di antara mode cepat; biayanya I/O per-mutasi.

Persistent — state lengkap diflush secara periodic async setiap 5 detik tanpa menghambat jalannya request (flush di thread belakang). Window kehilangan maksimal ~5 detik mutasi terakhir bila proses dibunuh mendadak.

Tip

Aturan praktis: CI/unit test pakai memory; dev harian pakai persistent; WAL untuk eksperimen yang menuntut zero-loss antar restart; hybrid kalau ragu.

#Trade-off

#Kecepatan vs Durability Antar Restart

Kerangka keputusan cepat:

100%

Ingat konteks pemakaiannya: emulator lokal untuk development/testing. "Kehilangan data" di sini artinya mengulang beberapa langkah setup manual — bukan insiden produksi. Jadi jangan over-engineer: WAL untuk semuanya biasanya pemborosan.

#Praktik

Target outline: benchmark restart-persistence ketiga mode pada dataset sama.

#!/usr/bin/env bash
set -euo pipefail
MODE=${1:?pilih: memory | wal | persistent}
 
docker rm -f floci-bench >/dev/null 2>&1 || true
docker run --rm -d --name floci-bench \
  -e FLOCI_STORAGE_MODE=$MODE -p 4566:4566 \
  -v floci-bench-$MODE:/app/data floci/floci:latest
sleep 1
export AWS_ENDPOINT_URL=http://localhost:4566
 
# seed 1000 object
aws s3 mb s3://bench >/dev/null
for i in $(seq 1 50); do
  echo "payload $i" | aws s3 cp - s3://bench/obj-$i.txt >/dev/null &
done; wait
echo "$MODE: 50 objek seeded"
 
# kill keras lalu nyalakan ulang
docker kill floci-bench >/dev/null
docker run --rm -d --name floci-bench \
  -e FLOCI_STORAGE_MODE=$MODE -p 4566:4566 \
  -v floci-bench-$MODE:/app/data floci/floci:latest
sleep 1
 
SURVIVED=$(aws s3 ls s3://bench --recursive | wc -l)
echo "$MODE: selamat $SURVIVED/50 objek"

Amati dua variabel: jumlah objek yang selamat dan waktu total skrip per mode. Selisih durasi seeding antar mode adalah proksi kasar biaya write-nya — memory tercepat, WAL paling lambat, persistent di tengah.

Note

Volume Docker per mode (floci-bench-$MODE) menjaga percobaan bersih dan dapat direproduksi. Hapus volume saat selesai: docker volume rm.

#Penutup

Rangkuman episode ini:

Empat profil: memory (tercepat, volatile), hybrid (checkpoint), WAL (log per-mutasi, zero-loss), persistent (async flush 5 detik).
Pilih per skenario: CI → memory; dev jangka panjang → persistent; zero-loss → WAL.
Benchmark restart pada dataset sama membuktikan klaim durability dengan angka sendiri.

Episode 16 membahas konfigurasi lainnya: environment variables Floci — termasuk tabel translasi LocalStack untuk migrasi drop-in compose kalian. Sampai jumpa!