Scaling on queue length with the HPA

WHAT THIS TESTS Whether you know the HPA cannot read arbitrary sources directly and understand the adapter-based metrics pipeline that feeds it.

A GOOD ANSWER COVERS The HorizontalPodAutoscaler does not connect to your message broker. It reads metrics only through the Kubernetes aggregated metrics APIs: metrics.k8s.io for resource metrics served by metrics-server, and custom.metrics.k8s.io or external.metrics.k8s.io served by an adapter you deploy. For queue length, which is not tied to a pod, you use an external metric. The pipeline is: the queue's depth is collected, often scraped into Prometheus or read from the broker, then an adapter such as the Prometheus Adapter or a KEDA scaler exposes that value through the external metrics API. You then write an HPA with a metric of type External naming the queue-length metric and a target value, typically a target per pod like messages per replica. Each cycle the HPA fetches the current value and computes desired replicas roughly as current divided by per-pod target, scaling out as the backlog grows and in as it drains. KEDA is the common production choice because it ships ready-made scalers for Kafka, SQS, RabbitMQ and more, and can scale to zero.

COMMON WRONG ANSWERS Saying the HPA queries the queue directly; it only consumes the metrics API. Believing the HPA supports just CPU and memory. Using a custom (per-object) metric where an external metric is appropriate for a queue not associated with a pod. Forgetting to deploy and register the adapter, so the metric is unavailable.

LIKELY FOLLOW-UPS What is the difference between custom and external metrics? How does the HPA's scaling formula and stabilization window prevent flapping? How does KEDA differ from a raw HPA and how does scale-to-zero work? How do you avoid thrashing when the queue is bursty?

ONE CONCRETE EXAMPLE Workers consume an SQS queue. You deploy KEDA with an SQS scaler targeting thirty messages per pod. KEDA exposes the queue depth via the external metrics API and manages an HPA. When the queue holds 300 messages, the HPA targets about ten replicas; as workers drain it to 30, it scales back toward one, and KEDA can scale to zero when the queue is empty.