Choosing the Right Autoscaling Metrics for Java Services on EKS

The general direction makes sense, but the metric should reflect the real bottleneck rather than just the service category. CPU is often a good first metric for HTTP services and is simpler and more reliable than immediately adding custom request-rate metrics. If request volume, latency, or concurrency clearly predicts saturation better than CPU, then a Prometheus-based metric can be worthwhile. For queue consumers, scaling from backlog or estimated backlog-per-worker is a common approach, including KEDA with SQS. Just remember that adding workers will not fix a downstream bottleneck. If PostgreSQL or another dependency is already saturated or slow, scaling the Java pods may increase contention and make the system worse. Validate the dependency capacity and observe CPU, latency, throughput, queue age, and error rates together. To verify the classification, inspect actual ingress and service-routing configuration, application access logs, SQS consumer metrics, and dependency telemetry. Then compare CPU, heap usage, request rate, latency, throughput, and queue depth during representative load tests. The metric that rises predictably before saturation—and produces a useful scaling response—is generally a better choice than memory alone.