A global electronic shelf-label platform provider (named reference under NDA) had an image-generation service that could not reach its own target, and a cost line growing faster than its customer base. We re-architected it to scale on demand and cut infrastructure cost while doing it.
The provider's electronic shelf labels are only as good as the service that renders them. That image-generation microservice was the bottleneck: it was expected to produce 1,200 images per second and was managing only about 650. Under load, the design leaked events, distributed jobs unevenly, and burned resources it did not need — which meant inconsistent output and a cost line that grew faster than the customer base.
For a platform billing on scale, that is an existential constraint. Every new retail customer added load, and the service could not absorb it without either degrading or over-provisioning. The team needed throughput and efficiency together, not one at the expense of the other.
The core problem: a microservice whose scaling model did not match the bursty, event-driven nature of its own workload.
We redesigned the service around event-driven autoscaling using KEDA, the Kubernetes Event-Driven Autoscaler. Instead of scaling on coarse infrastructure signals, the service now scales on the actual event backlog in the queue, spinning capacity up as work arrives and back down as it clears.
The hard part was scaling down. KEDA does not handle in-application shutdown signals cleanly, so naive scale-down dropped in-flight events. Rather than push that complexity into the application, we implemented a Kubernetes preStop hook to drain work gracefully before a pod terminated — eliminating event loss during scale-down and keeping throughput steady regardless of how aggressively the service flexed.
The result was a service that tracked its workload precisely: full capacity under burst, minimal footprint when idle, and no events lost in either direction.
There is no model anywhere in this system. It is Kubernetes, a queue and a scaling policy. We owned the throughput and cost targets, re-architected against them, and proved the numbers in production — engineering outcomes rather than engineering effort. This one sat with Platform Delivery & Operations start to finish, under a single named lead answerable for both the throughput number and the cost one.
Density improved with it: a single instance now serves many more retail customers, which is the number that actually moves unit economics on a platform billing by scale.
The two engineering decisions that produced this are both unglamorous. Scaling on queue depth rather than on CPU means the service reacts to the work rather than to a symptom of the work. And handling drain in a preStop hook rather than in application code means every future service on that cluster inherits correct shutdown behaviour without its authors having to think about it.
Stack — Kubernetes · KEDA event-driven autoscaling · preStop drain hooks · queue-depth scaling triggers
Tell us the throughput you need and the bill you are paying for the throughput you have. We will tell you whether it is an architecture problem or a capacity one.
