Anda tidak perlu rewrite apapun saat bisnis tumbuh. Cukup pindah ke server lebih besar atau pisahkan komponen. Hooks-nya sudah ada di kode.
Salah satu pertanyaan paling sering dari calon mitra reseller: "kalau saya mulai kecil, terus customer saya tumbuh ribuan, sistemnya sanggup nggak?". Jawabannya: sanggup, tanpa rewrite. Halaman ini menunjukkan jalan dari Tier 1 (4GB VPS Contabo Rp 200rb/bulan) sampai Tier 5 (multi-region Kubernetes).
Semua angka di bawah berasal dari load test internal nyata di kode (lihat docs/system/LOAD_TEST.md, 1281 baris) — bukan estimasi marketing. Harga server adalah harga publik 2026 di Indonesia (Hetzner Cloud, Contabo, Biznet GIO, DigitalOcean Singapura).
1 customer biasanya pakai 1-3 device WhatsApp. Jadi 100 customer ≈ 100-300 device ≈ 200-600 MB RAM hanya untuk session whatsmeow.
1 customer kirim/terima rata-rata 50-200 pesan/hari. 100 customer × 100 pesan × 365 hari ≈ 3.6 GB/tahun (bisa di-archive).
1 customer biasanya buka 1-3 tab dashboard. 100 customer ≈ 200 koneksi WS aktif ≈ 16 MB RAM.
Broadcast 100rb pesan ≈ 15 MB Asynq queue payload. Aman di Tier 2 (6-8 GB RAM).
Rule of thumb: 1 customer aktif ≈ 5-10 MB RAM (whatsmeow + WS + buffer). 100 customer = ~500 MB-1 GB RAM dipakai untuk customer-state. Sisanya untuk OS, Postgres, Redis, dan margin.
DB_MAX_OPEN_CONNS=60, Asynq concurrency tetap 50
shared_buffers=2GB
shared_buffers=4GB)
business_id hash range
Catatan: harga di atas tidak termasuk bandwidth (biasanya 5–20 TB termasuk gratis di Hetzner/Contabo) dan storage backup eksternal.
Kalau antrian broadcast penuh, sistem tolak pickup baru — tidak crash, tidak OOM. Pelanggan tetap dapat error message yang jelas.
250 RPS per phone, otomatis. Anda tidak perlu khawatir kena rate limit Meta Graph API.
Kalau heartbeat lock hilang (instance lain ambil alih), batch dibatalkan otomatis — tidak ada double-send ke device sama yang bisa trigger WhatsApp ban.
Query lama otomatis di-cancel — tidak ada goroutine yang block tak terbatas walau ada bad query.
Saat deploy ulang, sistem drain request + close koneksi WS dengan timeout 1 detik per client. Tidak ada data corrupt karena force-kill.
Task gagal? Auto-retry dengan backoff cerdas. Anda hanya lihat task yang benar-benar tidak bisa diselesaikan.
Tier 1: DB_MAX_OPEN_CONNS=25. Tier 4: =120. Cukup ubah env variable, restart.
Tier 1: concurrency=20. Tier 4: =200 per worker × 2 worker shard. Env variable saja.
Tier 4 mulai pakai WORKER_SHARD_RANGE=0-50% dan =50-100% di 2 instance — hash range business_id split otomatis.
Tier 4: queue, throttle, dan pubsub bisa pakai 2 Redis instance terpisah via REDIS_QUEUE_URL + REDIS_CACHE_URL — sudah ready.
Tier 4: query read-heavy bisa diarahkan ke replica via db.Pool.Read() — scaffold sudah ready, opt-in per repository saat butuh.
Endpoint /health cek DB + Redis. Cache invalidate cross-instance via Redis pub-sub — sudah jalan untuk multi-replica deploy.
Ngobrol dengan tim kami 30 menit — kami bantu hitung sizing berdasarkan jumlah customer target, volume pesan estimasi, dan budget infrastruktur.