DigitalOcean Load Balancer to Droplets: which boundary to scale when latency appears only under concurrent load

We run an HTTP service behind a DigitalOcean Load Balancer forwarding to a small pool of Droplets. Under low traffic, p99 latency is flat. When we ramp concurrent clients, tail latency climbs sharply, and we cannot tell whether the bottleneck is the load balancer tier or the backends.

Our understanding of the documented behavior: the load balancer terminates client connections and opens separate connections to the Droplets, so tail latency depends on both sides. Health checks that turn slow under load can flap backends in and out of rotation, and connection reuse between the load balancer and Droplets can force fresh handshakes during bursts. On the Droplet side, CPU steal, conntrack limits, or application thread pools only saturate at concurrency, which looks identical to network latency without metrics.

The unresolved decision is the scaling axis: resize the load balancer to a larger tier versus adding more backend Droplets. DigitalOcean documents per-tier connection and request limits, but we have not found guidance on how to attribute queuing to one boundary or the other before spending on either.

Specifically:

• Which load balancer and Droplet metrics best distinguish load balancer queuing from backend saturation during a concurrency ramp?
• Is there a documented way to observe connection churn or health-check-driven backend removal as a latency cause?
• Given a fixed budget, what decision rule do operators use to choose between a larger load balancer tier and more Droplets?

Assume current-generation load balancer tiers; exact limits need verification against current docs.