Great article an idea, have been doing the research and proof-of-concept on this topic as well.

Here are my considerations:

KEDA functioning as a proxy does introduce some latency, but does it really qualify as a single point of failure? Couldn't you address this by scaling it for high availability? Additionally, the eBPF program itself can also be considered a single point of failure. While the verifier ensures the code adheres to strict safety and performance guidelines, it cannot fully guarantee flawless execution in every scenario.

Regarding latency, KEDA is typically deployed between services running in close proximity—whether within a local cluster of nodes or on the same machine. There might be cases where requests to KEDA originate from external networks, but how common are these use cases? Could you provide specific examples?

Also, if latency is a primary concern, you've likely already optimized your service architecture to minimize it. And if you rely on an eBPF program that preemptively starts containers on a SYN packet, the time difference between the SYN packet and actual request in a low-latency network is <50ms. Does optimizing for such a small window provide a significant advantage for any applications? How critical is this optimization in real-world scenarios?