> ## Documentation Index
> Fetch the complete documentation index at: https://kw.hellenictechnologies.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Scaling

> Horizontal and vertical scaling strategies.

Scaling is the answer to load that exceeds what a single server can handle — but it must be designed in, not bolted on. Horizontal scaling (adding more instances) is preferred over vertical scaling (larger instances) because it is cheaper, more resilient, and allows zero-downtime capacity changes. Hellenic Technologies designs applications and infrastructure for horizontal scale from the start, avoiding shared mutable state on individual servers.

Auto-scaling groups react to demand automatically. On AWS, Auto Scaling Groups scale EC2 instances based on CloudWatch metrics — typically CPU utilisation, request count per target, or custom application metrics published to CloudWatch. We set conservative scale-out thresholds (60-70% CPU) and aggressive scale-in cooldowns to prevent thrashing, and maintain a minimum fleet size that handles baseline traffic without cold-start delay. Kubernetes Horizontal Pod Autoscaler provides equivalent functionality for containerised workloads.

Database scaling presents different challenges. For read-heavy workloads, read replicas distribute SELECT queries across multiple database instances, reducing load on the primary. We configure application-level read/write splitting or use PgBouncer/ProxySQL to route queries automatically. For write-heavy workloads requiring horizontal scale, we evaluate sharding, CQRS patterns, or migration to distributed databases (CockroachDB, PlanetScale) based on the consistency requirements.

**Horizontal scaling services:**

* AWS Auto Scaling Group configuration with CloudWatch scaling policies
* GCP Managed Instance Group autoscaling and GKE node pool autoscaling
* Kubernetes HPA with CPU, memory, and custom metric triggers
* KEDA (Kubernetes Event-Driven Autoscaling) for queue-based scaling
* Database read replica setup and application-level read/write splitting
* PgBouncer connection pooling to handle burst database connection load
* Queue worker scaling with Celery, Sidekiq, or BullMQ on Kubernetes
* Load testing to validate scaling behaviour before production traffic
* Capacity planning reports with growth projections and scaling cost estimates
* Stateless application design review for horizontal scale compatibility
