Pular para o conteúdo principal

Capacidade e Escalabilidade

Estimativa de Carga (Setup Base)

Setup base: 2-4 vCPUs por serviço, PostgreSQL dedicado, Redis dedicado.

ComponenteCapacidade EstimadaGargalo Principal
Runner (1 instância)~500-1.000 items/minCPU + latência APIs externas
Runner (3 instâncias)~1.500-3.000 items/minRedis throughput
BullMQ (Redis)~10.000-50.000 jobs/minMemória Redis
PostgreSQL (writes)~5.000-10.000 inserts/minDisco + connections
http_logs (async)~15.000-30.000 logs/minFila logs + batch insert

Na prática: o gargalo real é a latência das APIs externas. Se cada push leva 200ms, um worker processa ~300 items/min. Com concurrency 10 por handler, sobe para ~3.000/min por instância.

Volume Suportado Sem Mudança de Arquitetura

FaixaItems/diaRequisitos
Confortávelaté 100.000Setup base, sem ajustes
Com tuningaté 500.000Mais instâncias Runner, batch inserts no DB
Limiteaté 1.000.000Redis Cluster, PgBouncer otimizado, múltiplas instâncias de todos os serviços

Ordem de Saturação

Para Ultrapassar 1M+ Items/Dia

Requer mudança arquitetural:

  • Substituir BullMQ por Apache Kafka (throughput massivo)
  • Database sharding por tenant
  • Separar Log Writer em serviço dedicado
  • Considerar event sourcing

Para o cenário de integrações CRM, dificilmente o volume ultrapassa 500K items/dia.

Mecanismos de Escalabilidade Já Previstos

MecanismoFaseDescrição
Escala horizontal do RunnerNativoBullMQ suporta N workers concorrentes
Concurrency por handlerFase 2Controle fino na tabela configs
Rate limiting por handlerFase 2Proteção contra throttle de APIs externas
Logs assíncronosFase 2Fila logs desacopla escrita do processamento
PgBouncerFase 5Connection pooling para N instâncias
Redis SentinelFase 5Alta disponibilidade e failover automático
Métricas de filaFase 5Prometheus + Bull Board para observabilidade
Pausa por handlerFase 5Backpressure granular
Retenção diferenciadaFase 5Logs 30 dias, executions 6 meses