Skip to main content
Welcome. In this lesson we’ll use KEDA to scale worker services based on backlog queued in a Redis list. This pattern is useful for an online store under heavy load: orders arrive faster than a worker can process, the Redis list grows, and we need to scale workers based on queue length (not CPU or memory).
The image is a simple diagram titled "E-Commerce Story" showing a laptop filled with many shopping-cart icons (representing heavy traffic during a big sale or holiday season) and a connection to a “Worker Service” server on the right. Circling cart icons on the left indicate incoming user requests.
Conceptually, KEDA watches Redis for the number of items in a list and scales the worker Deployment (or other scalable controller) up or down to match demand. The pieces involved:
  • A Kubernetes Secret to store Redis credentials.
  • A KEDA TriggerAuthentication to expose secret values to KEDA triggers.
  • A KEDA ScaledObject that defines the Redis trigger and HPA behavior.
A simple diagram showing the Redis logo on the left with arrows to two turquoise icons (a stacked-layers icon and a people icon) that both point to the KEDA hexagon logo on the right.
These objects work together so KEDA can react to backlog changes and adjust replicas of your worker service automatically.
A presentation slide titled "KEDA Scaling With 'redis' List" showing three colored icons labeled Secret, TriggerAuthentication, and ScaledObject. Each icon is inside a rounded speech-bubble shape with a key, gears, and a dashed square symbol respectively.
Quick reference — what you’ll create: Below is a minimal combined manifest including all three objects. It shows how to provide the Redis password, how TriggerAuthentication exposes it to KEDA, and how ScaledObject configures the redis trigger and advanced HPA behavior.
Base64-encoding Secrets only obfuscates values; it is not secure by itself. For production, use a proper secret-management solution such as sealed-secrets, external secret stores, or your cloud provider’s secret manager.
Important fields explained
  • Secret (auth-redis-secret)
    • redis_password must be Base64-encoded in the Secret and referenced by TriggerAuthentication.
  • TriggerAuthentication (keda-trigger-auth-redis-secret)
    • Maps the secret key to a trigger parameter. In this manifest, it exposes the secret as the password parameter for the Redis trigger.
  • ScaledObject (redis-scaledobject)
    • scaleTargetRef.name must match the target Kubernetes object you want to scale (Deployment, StatefulSet, etc.). The example uses nginx as a placeholder — replace it with your worker Deployment name.
    • Trigger type redis monitors the Redis list specified under listName: mylist.
    • listLength: "10" defines the threshold used by the scaler: when the list length exceeds this value, KEDA will consider scaling up.
    • address should point to your Redis service using the Kubernetes DNS format: service.namespace.svc.cluster.local:6379.
    • advanced.horizontalPodAutoscalerConfig.behavior controls scaling velocity:
      • scaleUp: here allows up to 100% increase (doubling pods) every 15s.
      • scaleDown: more conservative — up to 50% reduction every 20s with a 20s stabilization window to avoid flapping.
Best practices and tips
  • Tune listLength, minReplicaCount, and HPA behavior according to processing time per item and acceptable latency.
  • If Redis is externally hosted, ensure network connectivity and correct address format.
  • Test scaling in a staging environment first to observe real-world scaling behavior before production roll-out.
Additional resources
Make sure scaleTargetRef.name matches your actual Deployment/scale target and that KEDA has permission to scale it. Misconfigured names or RBAC can prevent scaling from taking effect.

Watch Video

Practice Lab