Engineering · 2 min read
Headless Service DNS Capacity Model
A simple formula ties per-pod ceiling and Ready pod count to maximum concurrency. Three KEDA settings defend against cold-start spikes.
The Formula
A headless Service returns one DNS record per Ready pod. Pending pods do not appear in DNS. The client sees only pods that can accept work.
Three Facts That Set Capacity
- Per-pod ceiling. The maximum concurrent requests one pod can handle before it times out or OOMs. Measure it by burst-testing one pod alone.
- Ready pod count. Only pods that pass the readinessProbe appear in DNS. Pods that are still starting are invisible.
- Failure window. The gap between “KEDA triggers scale-up” and “new pods pass readiness.” During this gap, existing pods absorb all load. If the burst exceeds their ceiling, requests fail.
Three Defenses Against Cold-Start Spikes
minReplicas: the baseline pod count. It absorbs the first burst without waiting for KEDA.cooldownPeriod: keeps pods alive after a spike. It absorbs repeated bursts.fallbackReplicas: holds the pod count when Prometheus is unreachable.
Real numbers from testing. 3 pods handled 150 concurrent (about 50 per pod). At 200, 99 requests returned 502. At 200 with 6 warm pods, 199/200 succeeded. The per-pod ceiling is approximately 50.
References:
Related: see how KEDA pressure testing validates these numbers, or go back to the series overview.