這個案例的核心責任是說明 event-driven workload 該按 backlog 而非 resource usage scale 的設計判準。

觀察

Trivago 跨 3 個 region 跑 50+ Kafka sink service、每個 always-on 用 1 CPU + 1 GB；CPU/mem-based autoscaling 無效（sink 多為 I/O bottleneck、CPU 平坦）。

判讀

KEDA 以 consumer lag 為 scaling signal、minReplicaCount=0 達到 scale-to-zero、daily replica-hour 從 50 降到 1-2。揭露「resource usage 不等於工作量」、event-driven 場景該看 backlog signal。

對應大綱

Kafka 進階主題：consumer lag / autoscaling / multi-tenant 配額。

下一步路由

回 Kafka vendor 頁 與 3.4 consumer 設計。

引用源