Blueprint SQLite High-Traffic — Cara Laju Go Menangani Ratusan Ribu Request

Di dua tulisan sebelumnya, kita sudah bahas kenapa SQLite itu efisien dan bagaimana Litestream menjaganya tetap aman. Sekarang pertanyaannya: “Gimana cara setup-nya supaya kuat nahan beban production yang masif?”

Banyak yang kaget, tapi dengan optimasi yang tepat, SQLite bisa menangani 100.000+ Request Per Second (RPS) di server tunggal. Begini resep rahasianya:

---

1️⃣ Database Tuning (The PRAGMA Magic)

Jangan pakai settingan default. Segera setelah koneksi database dibuka di Go, paksa SQLite keluar dari “mode hemat” dengan perintah ini:

• Mode WAL: PRAGMA journal_mode = WAL; (Wajib! Agar Read & Write tidak saling blokir).
• Synchronous NORMAL: PRAGMA synchronous = NORMAL; (Sangat cepat & tetap aman dalam mode WAL).
• Memory Mapping: PRAGMA mmap_size = 2147483648; (Mapping 2GB ke virtual memory untuk I/O instan tanpa syscall overhead).
• Busy Timeout: PRAGMA busy_timeout = 5000; (Agar aplikasi sabar mengantre 5 detik sebelum memunculkan error ‘database locked’).

---

2️⃣ Go Connection Pool Tuning

SQLite bukan PostgreSQL. Jangan buka koneksi tak terbatas. SQLite bekerja paling efektif dengan pool yang terkontrol ketat:

db.SetMaxOpenConns(100)           // Ideal untuk 16 vCPU (6-8x jumlah core)
db.SetMaxIdleConns(10)            // Menjaga koneksi tetap hangat
db.SetConnMaxLifetime(time.Hour)  // Recycle berkala

---

📊 Estimasi Resource: Berapa Biaya yang Dibutuhkan?

Untuk menghandle ratusan ribu traffic, Anda tidak butuh cluster database raksasa seharga ribuan dollar. Cukup satu Powerful Single Node.

Rekomendasi Spek Server (Vultr HF / DigitalOcean Premium):

• CPU: 16 vCPU (High Frequency).
• RAM: 32GB - 64GB (4GB untuk SQLite Cache, sisanya biarkan dipakai OS Page Cache).
• Storage: NVMe SSD (Wajib! Latensi tulis sangat bergantung pada Disk IOPS).

Estimasi Biaya: ~$150 - $250 / bulan. Bandingkan dengan Managed Database (RDS/Cloud SQL) dengan spek serupa yang bisa memakan biaya 5x hingga 10x lipat lebih mahal.

---

📈 Perhitungan Kapasitas (Target 100k RPS)

Jika traffic Anda terdiri dari 90% Read dan 10% Write:

• Read (90k RPS): Dengan latensi sub-millisecond (in-process), 16 vCPU sudah lebih dari cukup untuk menangani beban ini.
• Write (10k RPS): Selama Anda menggunakan NVMe, SQLite sanggup melakukan ~10k-15k sequential writes per detik di mode WAL.

Kesimpulannya: 100.000 RPS bukan lagi mimpi untuk SQLite. Anda mendapatkan database yang Zero Latency (karena tidak ada network hop) dan High Scale dalam satu paket hemat.

---

✅ Penutup Serial: Choose Boring Technology

Kita sering terjebak dalam tren “Distributed System” yang rumit padahal kebutuhan kita bisa diselesaikan dengan jauh lebih sederhana.

Laju Go memilih SQLite bukan karena “nekat”, tapi karena efisiensi:

1. Speed: Latensi terendah karena DB ada di dalam memori aplikasi.
2. Safety: Replikasi real-time via Litestream.
3. Simplicity: Satu file, tanpa drama maintenance cluster.

Berhenti menganggap SQLite itu mainan. Saatnya fokus pada fitur, bukan pusing urus infrastruktur.

SQLite is a high-performance engine built for the modern, efficient web. 🚀