Scaling Patterns
Horizontal vs vertical scaling strategies
Choose the right scaling approach for your workload.
Vertical Scaling (Scale Up)
Add more resources to single instance
When to Use
- Algorithms that don't parallelize well
- Small to medium graphs (<50M edges)
- Simpler deployment
Limits
- Single server capacity (typically 128 cores, 1TB RAM)
- No redundancy
- Expensive at large scale
Configuration
Pros: Simple, no coordination overhead
Cons: Limited by hardware, single point of failure
Horizontal Scaling (Scale Out)
Add more instances
When to Use
- Large graphs (50M+ edges)
- Independent workloads (batch jobs)
- High availability required
Patterns
1. Batch Job Parallelization
Process different time windows in parallel:
Deploy as Kubernetes Jobs:
2. Stateless API Tier
Multiple API servers behind load balancer:
Each instance handles independent queries.
3. Sharding by Entity
Partition by customer, region, etc:
Hybrid Approach
Vertical + Horizontal
- Scale up each instance for algorithm performance
- Scale out for throughput and availability
Example: 5 instances × 16 cores × 64GB = 320GB total capacity
Decision Matrix
| Graph Size | Workload | Pattern | Config |
|---|---|---|---|
| <10M edges | Single analysis | Vertical | 1× 8 cores, 32GB |
| 10-50M edges | Batch pipeline | Vertical | 1× 16 cores, 64GB |
| 50-100M edges | API + batch | Hybrid | 3× 16 cores, 64GB |
| 100M+ edges | Distributed | Horizontal sharding | 10× 32 cores, 128GB |
Auto-Scaling
Combine with HPA for dynamic scaling:
Cost Optimization
Vertical: Better CPU/memory efficiency, but more expensive at peak
Horizontal: Cheaper at rest (scale to zero possible), more complex
Recommendation: Start vertical, scale horizontal when needed
See Also
- HPA Scaling - Auto-scaling
- Resource Limits - Sizing
- Performance Optimization - Tuning