Why Standard HPA Fails
Think of a restaurant kitchen. The manager (HPA) decides how many chefs to hire based on how hard the existing chefs are sweating. If the chefs are calm and cool, the manager assumes business is slow — even if there's a massive pile of unread order tickets stacking up at the pass. The tickets (events) are the real signal, not the chefs' sweat (CPU).
The built-in Kubernetes Horizontal Pod Autoscaler (HPA) is great at one thing: scaling based on resource usage (CPU and Memory). For stateless web servers, this works well — more requests means more CPU, which triggers more pods. But for event-driven workloads, this model breaks down completely.
Consider a background worker processing jobs from an AWS SQS queue:
- Scenario: Suddenly, 10,000 jobs arrive in the queue.
- The Worker: It picks up one job, processes it efficiently using 10% CPU, then picks up the next.
- The HPA: It looks at the worker, sees 10% CPU usage, and thinks, "Everything is fine! No need to scale up."
- Result: The queue backlog grows infinitely, processing slows to a crawl, and your customers are angry — even though your cluster is sitting mostly idle.
This is the CPU Trap. The metric being measured (CPU) is completely decoupled from the actual pressure on the system (queue depth). Event-driven applications need to scale based on events — queue depth, Kafka consumer lag, database row count — not resource exhaustion.
Enter KEDA
KEDA (Kubernetes Event-Driven Autoscaling) is a CNCF project that solves this problem. It is a lightweight add-on that allows you to drive the scaling of any Kubernetes workload based on the number of events needing to be processed, pulling data directly from the event source rather than inferring load from CPU or memory.
Interviewers often ask: "When would you use KEDA instead of the standard HPA?" The answer is: whenever your scaling signal is external to the pod itself — queue depth, stream lag, cron schedule, or any metric not naturally expressed as CPU/memory. A strong follow-up is to mention that KEDA extends the HPA rather than replacing it, which shows you understand the architecture rather than just the use case.