Peak headroom or request throttling: sizing the Cassandra driver pool for bursts

Two ways to absorb bursts into a fixed pool

The DataStax Java Driver 4 sizes each node's connection pool statically at session start via PoolingOptions — maxConnectionsPerHost together with maxRequestsPerConnection. Nothing resizes the pool in response to load, so bursts that exceed the configured in-flight capacity end up rejected or queued depending on the driver version — the classic intermittent pool-exhaustion pattern.

Two documented levers pull in opposite directions. Size the pool for the peak: raise maxConnectionsPerHost so bursts always find headroom, accepting idle sockets and more connections per node. Or keep a modest pool and cap in-flight requests with the driver's request throttler (a concurrency-limiting throttler is one documented option), so bursts queue briefly instead of exhausting the pool, at the cost of tail latency.

Constraints worth weighing: the workload is bursty rather than steady; pool defaults and busy-pool behavior differ between driver 3.x and 4.x and need verification against the version in use; and node-side connection limits bound how far the headroom lever can go.

For intermittent, burst-driven exhaustion, which trade-off fits better — peak-sized headroom in the static pool, or throttled concurrency against a small pool? And which driver metrics (in-flight requests per connection, pool size, throttled-request counts) most reliably reveal which lever is the real bottleneck?