Latency spikes under concurrent bursts in Cosmos DB autoscale containers

An application using Cosmos DB autoscale provisioned throughput reports elevated request latency that appears only when many clients issue requests simultaneously. Single-client latency remains normal, and RU consumption metrics show a burst that precedes the latency increase. The concern is whether the delay between detecting increased demand and the actual RU/s scale-up is the primary cause, or whether partition hot-spotting and client connection pool exhaustion are contributing factors. Public documentation does not specify the exact timing, magnitude, or regional consistency of the autoscale ramp-up behavior, making it difficult to predict whether latency will recover before requests time out. The interaction between autoscale and multi-region writes or change feed processing under concurrent load is also unclear.

Is the latency spike primarily a consequence of the autoscale RU/s ramp-up delay, or should partition distribution and client-side connection limits be ruled out first? Does the scale-up timing and resulting latency vary by region or SDK version in ways that current documentation does not capture? What observable metrics or diagnostic signals can distinguish autoscale ramp-up latency from partition hot-spotting under concurrent bursts?