Você não precisa reescrever nada conforme o negócio cresce. Só mover para um servidor maior ou separar componentes. Os hooks já estão no código.
Uma das perguntas mais frequentes de potenciais parceiros revendedores: "se eu começar pequeno e meus clientes crescerem para milhares, o sistema aguenta?". Resposta: sim, sem rewrite. Esta página mostra o caminho do Tier 1 (VPS Contabo 4GB a R$ 70/mês) até Tier 5 (Kubernetes multi-região).
Todos os números abaixo vêm de load testing real interno do código (veja docs/system/LOAD_TEST.md, 1.281 linhas) — não estimativas de marketing. Preços de servidor são preços públicos 2026 (Hetzner Cloud, Contabo, AWS São Paulo, DigitalOcean).
1 cliente normalmente usa 1-3 devices WhatsApp. Então 100 clientes ≈ 100-300 devices ≈ 200-600 MB de RAM só para sessões whatsmeow.
1 cliente envia/recebe 50-200 mensagens/dia em média. 100 clientes × 100 msg × 365 dias ≈ 3,6 GB/ano (arquivável).
1 cliente normalmente abre 1-3 abas. 100 clientes ≈ 200 conexões WS ativas ≈ 16 MB de RAM.
Broadcast de 100 mil mensagens ≈ 15 MB de payload Asynq. Cabe confortavelmente no Tier 2 (6-8 GB de RAM).
Regra geral: 1 cliente ativo ≈ 5-10 MB de RAM (whatsmeow + WS + buffer). 100 clientes = ~500 MB-1 GB de RAM para estado de cliente. O resto é OS, Postgres, Redis e folga.
DB_MAX_OPEN_CONNS=60, Asynq concurrency fica em 50
shared_buffers=2GB
shared_buffers=4GB)
business_id
Nota: preços acima não incluem banda (geralmente 5–20 TB grátis no Hetzner/Contabo) e armazenamento de backup externo.
Quando a fila de broadcast enche, o sistema rejeita novos pickups — sem crash, sem OOM. Clientes recebem mensagem de erro clara.
250 RPS por telefone, automático. Você não precisa se preocupar com rate limit do Meta Graph API.
Se o heartbeat lock se perde (outra instância assumiu), o batch é abortado automaticamente — sem double-send para o mesmo device que poderia disparar ban do WhatsApp.
Queries longas são canceladas automaticamente — nenhuma goroutine bloqueia indefinidamente mesmo com query ruim.
No redeploy, o sistema dreina requests + fecha conexões WS com timeout de 1 segundo por client. Sem corrupção de dados por force-kill.
Task falhou? Retry automático com backoff inteligente. Você só vê tasks que realmente não podem ser concluídas.
Tier 1: DB_MAX_OPEN_CONNS=25. Tier 4: =120. Só mudar a env variable, restart.
Tier 1: concurrency=20. Tier 4: =200 por worker × 2 worker shards. Só env variable.
Tier 4 começa usando WORKER_SHARD_RANGE=0-50% e =50-100% em 2 instâncias — split automático por hash range de business_id.
Tier 4: queue, throttle e pubsub podem usar 2 instâncias Redis separadas via REDIS_QUEUE_URL + REDIS_CACHE_URL — já está pronto.
Tier 4: queries read-heavy podem ser direcionadas à replica via db.Pool.Read() — scaffold pronto, opt-in por repository conforme necessidade.
Endpoint /health verifica DB + Redis. Cache invalidate cross-instance via Redis pub-sub — já roda em deploys multi-replica.
Converse com nosso time por 30 minutos — ajudamos a dimensionar baseado em número de clientes-alvo, volume estimado de mensagens e budget de infra.