KEDA Event-Driven Autoscaling on Kubernetes: Architecture (2026)

KEDA event-driven autoscaling is the piece of the Kubernetes scaling story that the built-in Horizontal Pod Autoscaler was never designed to solve on its own: scaling a workload up and down in response to the depth of a Kafka topic, the age of the oldest message in an AWS SQS queue, the number of pending rows in a database table, or a Prometheus query, rather than the CPU it happens to be burning. KEDA does not replace the HPA — it extends it. It plugs a lightweight controller and a metrics adapter into the cluster so that queue depth and event backlog become first-class scaling signals, and it adds one capability the HPA cannot deliver alone: scaling all the way down to zero replicas when there is no work, then back up the moment work arrives. That combination is why KEDA event-driven autoscaling has become the default answer for asynchronous, bursty, and consumer-style workloads on modern clusters.

What this covers: the three internal components (operator, metrics adapter, scalers), the CRDs and the HPA KEDA generates, the scale-to-zero activation path, trigger and cooldown tuning, a real ScaledObject, and the failure modes that bite teams in production.

Context and Background

Kubernetes shipped horizontal autoscaling around a simple, defensible idea: watch a resource metric — usually CPU or memory — and add or remove pod replicas to hold that metric near a target. For request-serving web tiers this works well. Traffic correlates with CPU, CPU correlates with the metric the HPA reads, and the feedback loop is tight. The trouble starts the moment the workload is asynchronous. A queue consumer draining an SQS backlog might sit at 15% CPU while a million messages pile up behind it, because the bottleneck is network round-trips and downstream latency, not compute. CPU-based scaling stays flat while your backlog — and your end-to-end latency — climbs. The signal you actually care about, queue depth, is invisible to the HPA.

The second gap is scale-to-zero. The stock HPA has a floor of one replica; it will not scale a Deployment to zero even when there is provably nothing to do. For a nightly batch consumer, an internal tool used twice a day, or a per-tenant worker in a large multi-tenant platform, that “always at least one pod” floor is pure waste multiplied across hundreds of services. On spot-heavy or GPU clusters the waste is expensive enough to show up on the monthly bill.

KEDA closes both gaps. It lets the HPA see external, event-based metrics through the standard Kubernetes external metrics API, and it manages the 0-to-1 transition itself so workloads can genuinely idle at zero. This is a different concern from node autoscaling — Karpenter or the Cluster Autoscaler add and remove machines so pods have somewhere to land. KEDA scales pods; the node autoscaler scales the capacity underneath them, a distinction I cover in depth in Karpenter node autoscaling for Kubernetes. KEDA is a CNCF graduated project — it cleared graduation in 2023 and, by the v2.20 line shipping in mid-2026, carries 70+ maintained scalers. For the authoritative component reference, the KEDA concepts documentation is the canonical source.

KEDA Architecture: Operator, Metrics Adapter, Scalers

KEDA is three cooperating processes plus a set of custom resources. The operator (a controller) watches ScaledObject and ScaledJob resources and owns the lifecycle — including the 0-to-1 activation. The metrics adapter implements the Kubernetes external metrics API so a standard HPA can read event-source values. The scalers are the pluggable connectors — Kafka, SQS, RabbitMQ, Prometheus, Redis, cron, and dozens more — that actually talk to event sources. KEDA never scales pods directly during normal operation; it configures a real HPA and lets Kubernetes do the arithmetic.

Figure 1: The KEDA event-driven autoscaling data path. A scaler polls the event source, the operator and metrics adapter expose the value through the external metrics API, and the generated HPA turns that number into a replica count on the Deployment. The operator handles the 0-to-1 activation edge directly. Long description: a left-to-right flow from event source to scaler to KEDA operator to metrics adapter to external metrics API to HPA to Deployment to pods, with a separate activation arrow from the operator to the Deployment for the zero-to-one transition.

The operator and the CRDs it reconciles

The operator is the brain. You describe intent declaratively with a ScaledObject (for Deployments, StatefulSets, or any resource exposing the /scale subresource) or a ScaledJob (for Kubernetes Jobs, used for batch work where each unit of work should run to completion in its own pod). When you apply a ScaledObject, the operator reconciles it into a concrete HorizontalPodAutoscaler owned by KEDA — you will see it in the cluster named keda-hpa-<scaledobject-name>, with scaledobject.keda.sh labels marking it as KEDA-managed. You do not write that HPA yourself; deleting the ScaledObject garbage-collects it.

The operator also owns the part the HPA cannot do. When minReplicaCount is zero and the workload is idle, the operator watches the configured triggers directly. The instant a trigger crosses its activation threshold, the operator scales the Deployment from 0 to 1. Only after there is a running pod does it hand steady-state 1-to-N scaling to the HPA, because the external metrics API cannot meaningfully drive an HPA whose current replica count is zero. This split — operator owns 0↔1, HPA owns 1↔N — is the single most important mental model for KEDA event-driven autoscaling, and most confusing behavior traces back to forgetting it.

The metrics adapter and the external metrics API

The HPA controller in Kubernetes knows how to consume three metric families: resource metrics (CPU/memory via the metrics server), custom metrics, and external metrics. KEDA’s metrics adapter registers itself as an APIService for external.metrics.k8s.io. When the generated HPA asks “what is the current value of trigger X for this ScaledObject?”, that query is served by the adapter, which returns the latest value the corresponding scaler observed — Kafka consumer-group lag, SQS ApproximateNumberOfMessages, a Prometheus query result, and so on. The HPA then applies its standard formula: desiredReplicas = ceil(currentReplicas × currentValue / targetValue). In other words, KEDA does not invent a new scaling algorithm. It feeds the existing one a better number. Everything you already know about HPA behavior — tolerance, sync period, stabilization windows — still applies, which is a feature, not an accident.

This is the architectural insight that makes KEDA event-driven autoscaling trustworthy in production: it is not a bypass of Kubernetes autoscaling, it is an adapter into it. The metrics adapter is a read path only — it never mutates workloads. It answers metric queries and nothing else, which keeps the blast radius of a bug small and makes the whole system auditable with tools you already run. If you want to see exactly what the HPA is acting on, kubectl get hpa keda-hpa-<name> -o yaml shows the live external metric values and the target, and kubectl describe scaledobject <name> shows the operator’s view: whether each trigger is active, the last poll time, and any fallback state. Because the adapter speaks the standard external metrics API, other controllers and dashboards that understand that API can observe the same values without knowing KEDA exists. Contrast this with a hypothetical autoscaler that pokes the /scale endpoint directly on its own schedule: you would lose the HPA’s stabilization behavior, its tolerance band that damps tiny fluctuations, and years of hardening. KEDA deliberately declines to reinvent any of that.

The scalers and how they poll

A scaler is a small connector that knows how to authenticate to one event source and read one scaling signal from it. KEDA ships 70+ of them and supports an external-scaler gRPC contract for anything not in the box (teams use it for custom queues, GPU utilization, and internal control planes). Each trigger in a ScaledObject names a scaler type and its metadata. On every pollingInterval the operator invokes the scaler to fetch the current value and to answer a separate boolean: is this source active at all? That “active” check is what gates scale-to-zero. A crucial architectural point: most built-in scalers poll. They ask the source on an interval; they are not push-based subscriptions. That polling model is simple and robust, but it sets a floor on reaction time and is the root of several tuning trade-offs discussed later. Authentication is factored out into a TriggerAuthentication (or ClusterTriggerAuthentication) resource so secrets, workload-identity bindings, and pod-identity references live outside the ScaledObject and can be reused across many workloads.

A ScaledObject can carry multiple triggers, and this is where the model becomes genuinely expressive. Each trigger produces its own metric on the generated HPA, and Kubernetes scales to the maximum replica count any single trigger demands. So a worker can be driven by Kafka lag and an SQS dead-letter queue and a Prometheus latency query at once, and whichever is under the most pressure wins. This “max wins” composition is what lets teams model realistic demand — a queue that spikes at month-end plus a steady baseline plus a scheduled warm-up — inside one declarative resource instead of gluing together several autoscalers. It is also why KEDA event-driven autoscaling scales down conservatively: every trigger must agree the workload is quiet before it can fall, which is a safe default for consumer workloads where under-provisioning shows up as growing backlog rather than dropped requests.

ScaledObject versus ScaledJob

The two CRDs model two different execution shapes. A ScaledObject scales a long-running Deployment or StatefulSet — pods that stay up and pull work continuously, like a streaming consumer. A ScaledJob instead creates Kubernetes Jobs, one (or a batch) per unit of work, and each pod runs to completion and exits. The distinction matters when a single message triggers a bounded, possibly long task — video transcode, a report render, a machine-learning inference batch — where you want exactly one pod per item, clean completion semantics, retries via the Job controller, and no risk of a partly drained pod being killed mid-task by a scale-down. With ScaledJob there is no HPA involved at all; the operator reads the scaler, computes how many Jobs the current backlog warrants (bounded by maxReplicaCount), and creates them. Choosing correctly up front avoids a lot of pain: reach for ScaledObject when work is a continuous stream your pods consume, and ScaledJob when work is a set of discrete, independently completing tasks. Both are first-class citizens of KEDA event-driven autoscaling, and both share the same scaler catalog and TriggerAuthentication plumbing, so the auth and connection knowledge transfers cleanly between them.

Scale-to-Zero, Triggers and Tuning

Scale-to-zero is the headline capability, and its mechanics reward precision. When a KEDA event-driven autoscaling workload is idle, the operator alone keeps watch. When the oldest configured trigger reports activity above its activation threshold, the operator drives the 0-to-1 transition, the first pod starts, and only then does the generated HPA take over 1-to-N scaling. Getting this right is mostly about four knobs — pollingInterval, cooldownPeriod, the activation-versus-target threshold split, and stabilization windows — plus honest expectations about cold starts.

Figure 2: The activation handshake. The scaler reports queue depth to the operator, the operator activates the first replica, then enables HPA-driven metric scaling so the workload can climb to N replicas. Long description: a sequence diagram in which the scaler reports queue depth to the operator, the operator activates the first replica on the Deployment, the pod reports running, the operator enables metric scaling on the HPA, and the HPA scales the Deployment to N replicas which then report ready.

Here is a representative ScaledObject for a Kafka consumer that idles at zero and bursts to fifty pods under lag:

apiVersion: keda.sh/v1alpha1
kind: ScaledObject
metadata:
  name: order-consumer
  namespace: payments
spec:
  scaleTargetRef:
    name: order-consumer        # the Deployment to scale
  minReplicaCount: 0            # allow scale-to-zero when idle
  maxReplicaCount: 50
  pollingInterval: 15           # seconds between scaler polls
  cooldownPeriod: 300           # wait 5 min of inactivity before 1 -> 0
  fallback:
    failureThreshold: 3         # after 3 failed polls...
    replicas: 5                 # ...hold at 5 rather than crash to zero
  advanced:
    horizontalPodAutoscalerConfig:
      behavior:                 # standard HPA v2 stabilization
        scaleDown:
          stabilizationWindowSeconds: 120
  triggers:
    - type: kafka
      metadata:
        bootstrapServers: kafka.payments:9092
        consumerGroup: order-consumer
        topic: orders
        lagThreshold: "100"       # target: ~100 msgs lag per replica
        activationLagThreshold: "10"  # wake from zero once lag > 10
      authenticationRef:
        name: kafka-trigger-auth

The two thresholds do different jobs and are constantly confused. activationLagThreshold (the activation threshold) is the on/off gate: below it the operator keeps the workload at zero; cross it and one pod starts. lagThreshold (the target) is what the HPA divides against to compute replica count once you are above zero. So activation decides whether to run at all; the target decides how many. Set activation too low and a single stray message wakes the whole workload; set it too high and real backlogs sit unserved. They are independent numbers and should be tuned independently.

cooldownPeriod governs only the last step down — 1 back to 0. After the trigger goes inactive, the operator waits this long before removing the final replica, so a workload that goes quiet for a few seconds does not thrash. It does not govern N-to-1 scaling; that is the HPA’s scaleDown stabilization window, which is why the example sets both. pollingInterval is the reaction-time floor: at 15 seconds, worst-case detection latency for new work is roughly 15 seconds plus pod start time. Shorten it for latency-sensitive queues, but remember every scaler poll is a call to the event source — aggressive intervals across hundreds of ScaledObjects can hammer a broker or hit cloud API rate limits.

Figure 3: The reconcile loop. The operator turns a ScaledObject into a managed HPA, polls on the configured interval, gates scale-from-zero on the activation threshold, and returns to zero only after the cooldown elapses. Long description: a flowchart beginning at ScaledObject applied, through operator reconcile and create managed HPA, into a polling loop with an activation decision that either scales from zero or stays at zero, then an HPA scale to N, and a load-drop decision that either returns to zero after cooldown or keeps scaling.

The fallback block matters more than its length suggests. If a scaler cannot reach its source — broker outage, expired credentials, a throttled cloud metrics API — KEDA would otherwise have no metric, and a metric-less HPA can collapse a workload toward its floor. fallback says “if polling fails N times in a row, hold at a fixed safe replica count instead,” which prevents a monitoring or auth blip from silently draining your consumers to zero during an incident.

Tracing one scaling decision end to end

It helps to walk a single decision through the whole KEDA event-driven autoscaling pipeline. Suppose the orders topic accumulates 4,000 messages of consumer lag while the workload sits at zero. On the next 15-second poll, the Kafka scaler reads lag = 4000 and reports the source active because 4000 exceeds the activation threshold of 10. The operator scales the Deployment from 0 to 1 and enables the generated HPA. The HPA now reads the external metric through the adapter — 4000 — and applies its formula against the target of 100 lag-per-replica: ceil(1 × 4000 / 100) = 40 replicas desired, capped at maxReplicaCount of 50, so it requests 40. Those 40 pods drain the backlog; as lag falls, subsequent HPA cycles compute smaller desired counts, and the scaleDown stabilization window smooths the descent so a brief dip does not immediately shed pods. Once lag stays under the target and the trigger reports inactive, the cooldownPeriod timer starts; when it elapses, the operator removes the final replica and the workload returns to zero. Every number in that sequence is inspectable, and every step is a component you can reason about in isolation.

Contrast this with the CPU-based HPA it replaces for this workload. A CPU HPA would have seen those 40 consumer pods sitting at maybe 20% CPU — well under any sane target — and concluded the workload was over-provisioned, scaling down while 4,000 messages waited. The signal was pointing the wrong way. That inversion, more than any single feature, is why queue-driven services move to KEDA event-driven autoscaling: the metric finally matches the thing that hurts users.

Scalers vary widely in signal quality and cost. A quick comparison of common ones:

Scaler	Typical signal	Push or poll	Scale-to-zero	Notes
Kafka	Consumer-group lag	Poll	Yes	Lag per partition; watch partition count as a ceiling
AWS SQS	Approx. messages / oldest-message age	Poll	Yes	Costs one API call per poll; mind CloudWatch/API limits
RabbitMQ	Queue length / message rate	Poll	Yes	Management API or AMQP; queue length is cheap
Prometheus	Arbitrary PromQL result	Poll	Yes	Most flexible; only as fresh as scrape interval
Redis	List / stream length	Poll	Yes	Great for lightweight custom queues
Azure Service Bus	Active message count	Poll	Yes	Pairs with workload identity for auth
Cron	Time window	Internal	Yes	Deterministic pre-warming for known peaks

A pattern worth stealing: combine a cron trigger with an event trigger on the same ScaledObject. KEDA scales to the maximum demanded across all triggers, so a cron trigger can hold a warm floor of, say, three pods during business hours to hide cold-start latency, while the Kafka trigger handles bursts on top. For custom signals, the Prometheus scaler is the universal escape hatch — anything you can express as PromQL becomes a scaling dimension, which is why teams already invested in metrics pipelines lean on it. If you are weighing that metrics stack, see OpenTelemetry vs Prometheus and Loki for edge observability.

Trade-offs, Gotchas, and What Goes Wrong

Cold starts are the tax on scale-to-zero. When a workload idles at zero, the first message pays for the full 0-to-1 path: detect on the next poll, schedule a pod, pull the image if it is not cached, start the container, warm the runtime, and connect to the source. That is easily 10-60 seconds — sometimes minutes on a heavy JVM or if a new node must be provisioned first. For latency-sensitive paths, either keep minReplicaCount at one (or a small cron-warmed floor) or accept that the first request after idle is slow. Scale-to-zero is a cost lever, not a free lunch.

Oscillation and thundering herd. Set thresholds too tight or pollingInterval too short and replicas flap up and down, thrashing connections and rebalancing consumer groups. The fix is the standard HPA scaleDown stabilization window plus a sane cooldown, not smaller intervals. The thundering-herd variant: hundreds of pods activating at once slam a cold downstream (a database, a rate-limited API) that was fine while the queue was quiet. Rate-limit downstream calls and cap maxReplicaCount to what dependencies can actually absorb.

Always-warm cost. minReplicaCount greater than zero is a direct, recurring bill — replicas × requests × hours, paid whether or not work arrives. It is often the right call for latency, but make it a deliberate decision per workload, not a copy-paste default. The cost is easy to underestimate at fleet scale: a one-pod floor on a single service is trivial, but the same default applied uniformly across two hundred workers becomes two hundred idle pods reserving CPU and memory the scheduler must honor, which in turn keeps nodes alive that the node autoscaler would otherwise reclaim. Audit floors periodically; a workload that was latency-sensitive at launch may tolerate a cold start a year later once traffic patterns have shifted, and reclaiming those floors is often the single largest efficiency win available.

Auth and secret sprawl. Every scaler needs credentials to its source. Inline secrets in ScaledObjects rot and leak. Use TriggerAuthentication/ClusterTriggerAuthentication with workload identity or pod identity so rotation is centralized; a broken credential shows up as failed polls, which is exactly when fallback earns its keep.

Metric staleness and the polling floor. Because most scalers poll, the HPA can act on data up to one interval old, and a Prometheus-backed trigger is only as fresh as its scrape. Do not expect sub-second reaction from a poll-based system, and account for that lag in SLOs. When workers themselves emit events, patterns like the sidecar-and-pub/sub model in Dapr distributed application runtime for microservices can reduce how much you lean on polling.

Partition and concurrency ceilings. A subtle trap with the Kafka scaler: consumer-group parallelism is bounded by partition count. If a topic has 12 partitions, the thirteenth pod has no partition to read and sits idle even though KEDA event-driven autoscaling dutifully created it because lag was high. The metric says “more work,” but the source cannot distribute it further. Cap maxReplicaCount at the partition count (or repartition) so you do not pay for pods that can never consume. Similar ceilings exist for any source with a fixed concurrency model — the autoscaler will happily overshoot a limit it does not know about, so encode that limit yourself.

Operator as a shared dependency. The KEDA operator and metrics adapter are cluster-wide singletons that every ScaledObject depends on. If they are unhealthy, no event-driven scaling happens — workloads freeze at their current replica count rather than crash, which is a safe failure mode, but a silent one. Run the KEDA components with resource requests, a PodDisruptionBudget, and their own alerting, and treat a stuck reconcile loop or a climbing metrics-adapter error rate as a platform incident. Because KEDA event-driven autoscaling sits on the critical path for capacity, its own observability is not optional.

Practical Recommendations

Treat KEDA event-driven autoscaling as an extension of the HPA you already run, not a parallel system. Start with the event signal that maps most directly to user-visible latency — usually queue depth or consumer lag — and set the target threshold to the amount of backlog one healthy replica clears comfortably in one polling window. Set the activation threshold independently and slightly above your idle noise floor. Default pollingInterval to 15-30 seconds and only shorten it for genuinely latency-critical queues after checking the load it adds to the source. Always configure fallback so an auth or monitoring blip cannot drain your consumers to zero mid-incident. Reach for scale-to-zero on bursty, tolerant, or spiky-but-idle workloads; keep a warm floor — a fixed minReplicaCount or a cron trigger — wherever cold-start latency would breach an SLO. Pair KEDA with a node autoscaler such as Karpenter so pod-level bursts actually find capacity, and lean on the Prometheus scaler when a built-in signal does not exist.

Roll it out incrementally. Do not flip a production consumer straight to minReplicaCount: 0 on day one. Start with the target threshold only and a non-zero floor, watch a week of real traffic on the generated HPA to confirm the metric tracks demand and the pod count is sane, then lower the floor toward zero once you have measured the actual cold-start budget and decided it is acceptable. Instrument the workload with two derived metrics from the start — time-to-first-pod after idle, and backlog age at peak — because those two numbers tell you whether the tuning is working far better than replica count alone. Finally, standardize the boilerplate: a shared ClusterTriggerAuthentication, a house default for pollingInterval and cooldownPeriod, and a linter that rejects ScaledObjects missing a fallback. When dozens of teams adopt KEDA event-driven autoscaling on the same platform, the difference between a calm rollout and a noisy one is almost entirely whether those defaults were set once, centrally, or left to each service to rediscover.

Pre-flight checklist:

• [ ] Activation threshold set independently of the target threshold, above idle noise
• [ ] fallback.replicas configured to a safe non-zero count
• [ ] pollingInterval justified against source load and rate limits
• [ ] scaleDown stabilization window and cooldownPeriod both tuned against oscillation
• [ ] maxReplicaCount capped to what downstream dependencies can absorb
• [ ] Credentials via TriggerAuthentication + workload identity, not inline secrets
• [ ] Node autoscaler present so bursts land on real capacity
• [ ] Cold-start budget measured and either accepted or hidden with a warm floor

Figure 4: Two scaling layers. KEDA scales pods from event signals; when the resulting pods are unschedulable, Karpenter provisions nodes; new capacity lets the pending pods run. Long description: a flowchart with a pod layer where KEDA drives the HPA to create pending pods, and a node layer where Karpenter provisions new nodes, with unschedulable pods triggering node provisioning and new capacity satisfying the pending pods.

Frequently Asked Questions

Does KEDA replace the Horizontal Pod Autoscaler?

No. KEDA event-driven autoscaling extends the HPA rather than replacing it. When you apply a ScaledObject, KEDA generates and manages a real HorizontalPodAutoscaler (named keda-hpa-<name>) and feeds it external event metrics through the Kubernetes external metrics API. The HPA still does the replica arithmetic for 1-to-N scaling. KEDA adds the two things the HPA cannot do alone: reading arbitrary event-source signals like queue depth, and scaling a workload to and from zero replicas.

How does KEDA actually scale to zero?

The KEDA operator handles the 0-to-1 edge itself, because a standard HPA will not drive a workload from zero and has a floor of one replica. While a workload is idle, the operator polls the triggers directly and checks whether each source is “active.” When a trigger crosses its activation threshold, the operator scales the Deployment from 0 to 1, then hands 1-to-N scaling to the generated HPA. On the way down, after the trigger goes inactive for the full cooldownPeriod, the operator removes the last replica.

What is the difference between the activation threshold and the target threshold?

They answer different questions. The activation threshold (for example activationLagThreshold) is an on/off gate that decides whether the workload runs at all — below it, KEDA keeps you at zero. The target threshold (for example lagThreshold) is what the HPA divides the current metric against to decide how many replicas to run once you are above zero. Set them independently: activation just above idle noise, target at the backlog one replica clears per polling window.

How is KEDA different from Karpenter or the Cluster Autoscaler?

They operate on different layers. KEDA scales pods based on event-driven signals; Karpenter and the Cluster Autoscaler scale nodes so those pods have somewhere to run. KEDA can create pending pods, but if the cluster lacks capacity they stay unschedulable until a node autoscaler provisions machines. In production you run both: KEDA for event-driven pod scaling and Karpenter for right-sized node capacity underneath. They complement, never substitute for, each other.

What are the main failure modes to plan for?

Cold-start latency on scale-from-zero, oscillation from thresholds set too tight, thundering-herd pressure on cold downstreams when many pods activate at once, recurring cost from an always-warm minReplicaCount, credential rot in scaler auth, and metric staleness from the polling model. Most are mitigated with stabilization windows, sensible cooldowns, a configured fallback, capped maxReplicaCount, and centralized TriggerAuthentication. None are blockers — they are the tuning surface of KEDA event-driven autoscaling.

How many event sources does KEDA support, and can I add my own?

The KEDA v2.20 line ships 70+ maintained built-in scalers covering messaging (Kafka, RabbitMQ, NATS), cloud queues (AWS SQS, Azure Service Bus, GCP Pub/Sub), databases, Prometheus, Redis, cron, and more. When no built-in scaler fits, KEDA exposes an external-scaler gRPC contract so you can implement a custom connector — teams use it for proprietary queues, GPU utilization, and internal control planes — without forking the project.

Further Reading

• Karpenter node autoscaling for Kubernetes — the node layer that pairs with KEDA
• OpenTelemetry vs Prometheus and Loki for edge observability — the metrics stack behind the Prometheus scaler
• Dapr distributed application runtime for microservices — event-driven building blocks that feed KEDA triggers
• KEDA concepts documentation — canonical component and CRD reference
• CNCF KEDA graduation announcement — project maturity and governance

By Riju — about