Skip to main content

Capacity Planning Guide

Resource requirements and scaling guidelines for Aragora deployments.

Table of Contents​

Resource Requirements​

Per-Debate Resource Consumption​

ResourcePer Active DebateNotes
Memory50-200 MBDepends on agent count, context size
CPU0.1-0.5 coresSpikes during LLM calls
Network1-5 MBLLM API traffic, WebSocket streaming
Database I/O10-50 ops/minCheckpoints, critiques, votes

Agent Resource Multipliers​

Agent TypeMemory MultiplierNotes
API agents1.0x baselineStateless, minimal memory
CLI agents1.5xSubprocess overhead
Local models5-10xModel weights in memory

Server Baseline Requirements​

ComponentMinimumRecommendedProduction
HTTP Server256 MB, 0.5 CPU512 MB, 1 CPU1 GB, 2 CPU
WebSocket Server256 MB, 0.5 CPU512 MB, 1 CPU1 GB, 2 CPU
Worker Process512 MB, 1 CPU1 GB, 2 CPU2 GB, 4 CPU

Scaling Guidelines​

Horizontal Scaling​

Multi-Worker Deployment​

# Start with multiple workers (recommended: 2-4x CPU cores)
aragora serve --workers 4 --host 127.0.0.1

Workers are assigned consecutive ports:

  • HTTP: 8080, 8081, 8082, 8083
  • WebSocket: 8765, 8766, 8767, 8768

Nginx Load Balancing​

upstream aragora_api {
    least_conn;  # Best for API traffic
    server 127.0.0.1:8080;
    server 127.0.0.1:8081;
    server 127.0.0.1:8082;
    server 127.0.0.1:8083;
}

upstream aragora_ws {
    ip_hash;  # Session affinity for WebSockets
    server 127.0.0.1:8765;
    server 127.0.0.1:8766;
    server 127.0.0.1:8767;
    server 127.0.0.1:8768;
}

Capacity Planning Matrix​

Concurrent DebatesWorkersRAMCPU CoresDatabase
1-1012 GB2SQLite
10-502-44-8 GB4-8SQLite
50-1004-88-16 GB8-16SQLite + Redis
100-5008-1632-64 GB16-32PostgreSQL + Redis
500+16+64+ GB32+PostgreSQL cluster

Vertical vs Horizontal Scaling​

ScenarioRecommendation
Memory pressureAdd workers (horizontal)
CPU bottleneckAdd workers or upgrade CPU
Database contentionMigrate to PostgreSQL
WebSocket connectionsAdd workers with ip_hash
LLM API rate limitsAdd API key rotation

Database Sizing​

SQLite Limits​

MetricSoft LimitHard LimitMitigation
Database size10 GB140 TBArchive old data
Concurrent writes11Use WAL mode
Concurrent readsUnlimitedUnlimited-
Connections502000Connection pooling

Growth Projections​

Data TypeGrowth Rate1 Month6 Months1 Year
Debates100/day3K18K36K
Critiques1K/day30K180K360K
Messages5K/day150K900K1.8M
Evidence500/day15K90K180K
Memory entries2K/day60K360K720K

Database Size Estimates​

DatabasePer 1K DebatesPer 10K DebatesPer 100K Debates
Consensus~5 MB~50 MB~500 MB
Continuum~10 MB~100 MB~1 GB
ELO~2 MB~20 MB~200 MB
Critiques~20 MB~200 MB~2 GB
Evidence~50 MB~500 MB~5 GB

Retention Policies​

Data TypeRecommended RetentionArchive Strategy
Active debatesIndefinite-
Completed debates1 yearArchive to cold storage
Critiques/patterns6 monthsArchive high-value only
Evidence90 daysTTL cleanup
Memory (fast tier)1 hourAuto-expire
Memory (glacial)30 daysPromote or archive
Audit logs2 yearsCompliance requirement

Monitoring Thresholds​

Resource Alerts​

MetricWarningCriticalAction
CPU utilization70%90%Add workers
Memory usage80%95%Increase RAM or workers
Disk usage70%85%Clean up or expand
Database size5 GB10 GBArchive data
Open connections100200Check for leaks

Performance Alerts​

MetricWarningCriticalAction
API latency p99500ms2000msProfile/optimize
WebSocket lag100ms500msCheck network/load
Debate duration5 min15 minCheck LLM latency
Query time100ms1000msAdd indexes
Queue depth50200Add workers

Circuit Breaker Thresholds​

Agent TypeFailure ThresholdRecovery Time
API agents5 failures30 seconds
External APIs3 failures60 seconds
Database2 failures10 seconds

Load Testing​

Benchmark Commands​

# Single debate benchmark
aragora benchmark --debates 1 --rounds 3 --agents 3

# Concurrent debate stress test
aragora benchmark --debates 10 --concurrent 5 --rounds 2

# Sustained load test
aragora benchmark --debates 100 --concurrent 10 --duration 3600

Expected Performance​

ScenarioDebates/HourLatency p50Latency p99
Light (1 worker)20-5030s120s
Medium (4 workers)100-20025s90s
Heavy (8 workers)300-50020s60s

Bottleneck Identification​

SymptomLikely CauseDiagnosis
High CPU, low throughputLLM rate limitsCheck API quotas
High memory, OOMContext accumulationEnable RLM compression
Slow queriesMissing indexesRun EXPLAIN ANALYZE
Connection timeoutsThread exhaustionIncrease workers
Intermittent failuresCircuit breaker tripsCheck external APIs

Infrastructure Recommendations​

Development​

# docker-compose.dev.yml
services:
  aragora:
    image: aragora:latest
    deploy:
      resources:
        limits:
          memory: 2G
          cpus: '2'
    environment:
      - ARAGORA_WORKERS=1

Staging​

# docker-compose.staging.yml
services:
  aragora:
    deploy:
      replicas: 2
      resources:
        limits:
          memory: 4G
          cpus: '4'
    environment:
      - ARAGORA_WORKERS=2

Production​

# kubernetes/deployment.yaml
spec:
  replicas: 4
  template:
    spec:
      containers:
      - name: aragora
        resources:
          requests:
            memory: "4Gi"
            cpu: "2"
          limits:
            memory: "8Gi"
            cpu: "4"
        env:
        - name: ARAGORA_WORKERS
          value: "4"

Cost Optimization​

LLM API Costs​

ProviderModelCost/1K tokensDebates/$
AnthropicClaude 3.5$0.003-$0.015~20-100
OpenAIGPT-4$0.03-$0.06~5-20
OpenRouterVarious$0.001-$0.01~50-500

Cost Reduction Strategies​

  1. RLM Compression: Reduce context by 40-60%
  2. Agent caching: Cache similar debate contexts
  3. Tiered models: Use cheaper models for critiques
  4. Batch processing: Combine small debates
  5. Evidence deduplication: Share evidence across debates

Capacity Planning Checklist​

Before Launch​

  • Baseline resource measurement complete
  • Database indexes optimized
  • Monitoring dashboards configured
  • Alert thresholds set
  • Backup strategy tested
  • Failover procedures documented

Monthly Review​

  • Review resource utilization trends
  • Check database growth rate
  • Analyze query performance
  • Review circuit breaker metrics
  • Update capacity projections
  • Plan infrastructure changes

Quarterly Review​

  • Load test with projected traffic
  • Review cost optimization opportunities
  • Update scaling thresholds
  • Test disaster recovery procedures
  • Review and update this guide