Prepare for a Planned Traffic Peak

This page helps you prepare for a traffic peak you can see coming — a launch, a marketing campaign, a seasonal sale or a large monthly batch — so the platform has the capacity in place before the load arrives.

What scales on its own, and what does not

Part	Scales automatically?	What to do
Nodes (AWS)	Yes — nodes are added when pods cannot be scheduled, up to each node pool's limit	Check the limit is high enough for your peak — see below
Application pods	Only if autoscaling is enabled on the Component	Enable it, or raise the minimum number of pods before the peak
Databases	No — the instance size is fixed	Ask CTO2B in advance; a resize may need a short maintenance window
Database connections	No — the limit follows the instance size	Check pool sizes against the number of pods you will run — see Database Refuses Connections With "Too Many Connections" or "Too Many Clients"

What you can do yourself

Set accurate resource requests. New nodes are added based on what pods request, not what they use. See Workload Resources and Health Checks.
Scale your application pods. Either enable CPU-based autoscaling in the Component's Helm values, or raise the minimum so the extra pods are running before the peak:

autoscaling:
  hpa:
    enabled: true
    minReplicas: 4
    maxReplicas: 12

A fixed replica count overrides autoscaling, which is why the v2 chart needs replicas: -1. To tell which chart a Component uses, see Deploy Without Downtime or Killing Running Work.

Check database connections at the maximum pod count. Each pod opens its own connection pool, so connections multiply with pods.
Run batch work on the job node pools, away from the services your users depend on — see CronJobs.
Make changes in SVIEW, not in the cloud console. A size or count changed directly in AWS or GCP is reverted — see Why Changes Made in the Cloud Console or with kubectl Are Reverted.

For scaling on queued work rather than CPU, see Event-Driven Autoscaling with KEDA.

Tell CTO2B ahead of time

Raise a request as early as you can — database changes in particular may need a maintenance window planned with you. Include:

the dates and times of the peak, in UTC, including when load ramps up and down;
the expected load as a multiple of normal (requests per second, concurrent users or jobs per minute), and the figures from the last peak if you have them;
the Services, Components and databases involved;
anything that was a bottleneck last time;
whether to scale back afterwards, and when;
a technical contact during the event.

CTO2B checks node pool limits, database size and connection limits against your figures, and plans any change with you.

Cost

Extra pods mean extra nodes, billed while they run, and a larger database or an added read replica costs more until it is scaled back. Plan to scale back after the peak.

Cluster Autoscaling — how nodes are added, and the node pools
Workload Resources and Health Checks — resource requests and limits
Database Refuses Connections With "Too Many Connections" or "Too Many Clients"
Add a Read Replica to a Database — spreading read load
Pod Stuck in Pending (FailedScheduling) — when new pods cannot be placed

What scales on its own, and what does not

What you can do yourself

Tell CTO2B ahead of time

Cost

Related articles