You do not have to rewrite anything as the business grows. Just move to a bigger server or split components. The hooks are already in the code.
One of the most frequent questions from prospective reseller partners: "if I start small and my customers grow into the thousands, will the system hold up?". Answer: yes, without a rewrite. This page shows the path from Tier 1 (4GB Contabo VPS at $13/month) up to Tier 5 (multi-region Kubernetes).
All numbers below come from real internal load testing on the code (see docs/system/LOAD_TEST.md, 1,281 lines) โ not marketing estimates. Server prices are 2026 public prices (Hetzner Cloud, Contabo, DigitalOcean, AWS Singapore).
1 customer typically uses 1-3 WhatsApp devices. So 100 customers โ 100-300 devices โ 200-600 MB RAM just for whatsmeow sessions.
1 customer sends/receives 50-200 messages/day on average. 100 customers ร 100 msg ร 365 days โ 3.6 GB/year (archivable).
1 customer typically opens 1-3 dashboard tabs. 100 customers โ 200 active WS connections โ 16 MB RAM.
A 100k-message broadcast โ 15 MB Asynq queue payload. Comfortably fits Tier 2 (6-8 GB RAM).
Rule of thumb: 1 active customer โ 5-10 MB RAM (whatsmeow + WS + buffer). 100 customers = ~500 MB-1 GB RAM for customer-state. The rest is OS, Postgres, Redis, and headroom.
DB_MAX_OPEN_CONNS=60, Asynq concurrency stays at 50
shared_buffers=2GB
shared_buffers=4GB)
business_id hash range
Note: pricing above excludes bandwidth (typically 5โ20 TB free at Hetzner/Contabo) and external backup storage.
When the broadcast queue is full, the system rejects new pickups โ no crash, no OOM. Customers get clear error messages.
250 RPS per phone, automatic. You do not need to worry about hitting the Meta Graph API rate limit.
When a heartbeat lock is lost (another instance takes over), the batch is automatically aborted โ no double-send to the same device that could trigger a WhatsApp ban.
Long queries are auto-cancelled โ no goroutine blocks indefinitely even with a bad query.
On redeploy, the system drains requests + closes WS connections with a 1-second per-client timeout. No data corruption from force-kill.
Task failed? Auto-retry with smart backoff. You only see tasks that truly cannot be completed.
Tier 1: DB_MAX_OPEN_CONNS=25. Tier 4: =120. Just change the env variable, restart.
Tier 1: concurrency=20. Tier 4: =200 per worker ร 2 worker shards. Env variable only.
Tier 4 starts using WORKER_SHARD_RANGE=0-50% and =50-100% on 2 instances โ automatic business_id hash-range split.
Tier 4: queue, throttle, and pubsub can use 2 separate Redis instances via REDIS_QUEUE_URL + REDIS_CACHE_URL โ already ready.
Tier 4: read-heavy queries can be routed to the replica via db.Pool.Read() โ scaffolding is ready, opt-in per repository as needed.
The /health endpoint checks DB + Redis. Cross-instance cache invalidation via Redis pub-sub โ already running for multi-replica deploys.
Talk to our team for 30 minutes โ we will help size your setup based on target customer count, estimated message volume, and infra budget.