Your Kubernetes worker pods are sitting at 100% CPU. Are they handling 10 tasks or 10,000? Your HPA has no idea, and neither do you.

Every team building background processing on Kubernetes hits this wall: video transcoding, PDF extraction, AI inference, document parsing. CPU and memory tell you how busy a worker is, not how much work is waiting. A fleet sitting at 100% CPU looks identical whether 10 tasks are queued or 10,000, and by the time a CPU-based autoscaler notices, the backlog has already been growing for an hour.

This session draws on real-world experience learning that lesson the hard way, and walks through why queue depth, not CPU, is the signal that actually works, and how Kubernetes, KEDA, Karpenter, Redis and Celery combine into a Fargate-like, scale-to-zero worker fleet, illustrated with a live reference implementation.

We'll cover:

- Why CPU/memory auto-scaling actively lies to you for queue-driven workloads
- KEDA: turning Redis/RabbitMQ/Kafka queue depth into real Kubernetes scaling decisions
- Karpenter: spinning up right-sized nodes only when pods actually need them
- ScaledObject vs. ScaledJob, and the mid-task pod deaths that push most teams toward the latter
- The defaults (pre-fetch multiplier, acks_late, visibility timeouts, retry ownership, one-queue-per-tier) that quietly break this architecture in production, and the fixes that hold up at scale

This talk covers the real trade-offs, failure modes, and lessons learned, the kind you only get from hitting this wall yourself, to help you build background processing on Kubernetes that scales to zero without paging you at 3 a.m.