ThrottleConfig

Concurrency-limiting request admission control (GH #81 / ISS-073). Wires the DataStax driver's own ConcurrencyLimitingRequestThrottler -- caps how many requests the driver will have in-flight against the cluster at once, queuing additional requests up to maxQueueSize instead of dispatching everything unbounded, and rejecting anything beyond that queue immediately with RequestThrottlingException.

Off by default: the driver's own default throttler (PassThroughRequestThrottler) never queues or rejects, which is what every existing Kandra deployment already runs under -- turning this on is an explicit choice a deployment makes once it wants controlled client-side backpressure against a slow or overloaded cluster (compaction storms, a partial multi-DC outage, a burst of application-side concurrency), rather than a behavior change that should surprise anyone who hasn't touched this block.

This only throttles at the driver/session level (session.execute/executeAsync admission). It is unrelated to and does not replace BatchEngine.inFlightCount, which is Kandra's own separate in-flight tracker used purely for graceful-shutdown draining.

A rejection surfaces to callers as io.kandra.core.exception.KandraThrottledException (GH #103 / ISS-090), not the raw driver RequestThrottlingException -- it participates in the same catch-Kandra's-documented-exceptions story as every other write/read failure. It is never retried by RetryConfig, regardless of retryOn: retrying a throttle rejection immediately just adds another request on top of an already-overloaded throttler.

Interacts with speculativeExecution: enabling both means each speculative retry counts as an additional request toward maxConcurrentRequests — turning both on can cause self-inflicted throttling under tail latency, since a burst of slow requests each spawn extra in-flight speculative copies right when the throttle is most likely to already be near its limit. Worth tuning maxConcurrentRequests/maxQueueSize up, or being conservative with speculative execution's own concurrency, if both are enabled together.