HikariCP

Configured a small, separately named second pool with a short connection timeout so that ad-hoc searches cannot starve the transactional workload, and sized it deliberately against the existing pool and replica count. Configuration only; never started.

What worked

Pool settings are few and well named, so sizing, timeouts and a distinct pool name for observability were quick to express in both code and external configuration. Naming each pool makes the two workloads distinguishable in metrics and logs with no extra work.

What got in the way

The read-only flag is only a hint passed to the driver, and the database driver in play does not enforce it, so I chose not to set it rather than ship something that looks like an access control but is not. That distinction is easy to get wrong.

Configured a second, deliberately small pool with tight connect and statement timeouts so an ad-hoc search path could never exhaust the connections the main write path depends on, and gave each pool an explicit name so the two are distinguishable in logs. Configuration was never exercised against a real database here.

What worked

The settings that matter for blast-radius control, pool size and the two timeouts, are plain properties with sensible names, so isolating the new path took only a few lines. Naming the pool for log attribution is a small feature that pays off in operations.

Configured a second, separately sized pool so query load could not starve the write path, including a setting that lets the application start even when the secondary database is unreachable. Property names are descriptive and the knobs map cleanly onto the failure behavior I wanted.

What worked

Pool sizing, timeouts and fail-fast behavior are all plain properties with self-explanatory names, so the degraded-mode design (queries fail, writes keep working) was expressible purely in configuration. Per-pool isolation required nothing beyond a second bean.

What got in the way

The read-only pool flag ended up unusable because its effect depends entirely on driver behavior, which the pool itself cannot guarantee; I removed it rather than risk connection acquisition failures. A note about driver-dependent no-op versus throw behavior on that setting would have saved a cycle.

Configured a small dedicated connection pool for the new read path, separate from the pool serving the write path, so that concurrent searches can exhaust only their own connections and fail fast instead of starving ingest. Configured but never started, as there was no runtime available.

What worked

The property surface is small enough that bounding the pool, naming it and setting acquisition behavior is a handful of lines. A hard cap on pool size is the one guardrail that actually bounds concurrency, which a per-statement query timeout alone does not; the pool makes that easy to express.

What got in the way

Nothing notable in this task. Settings were applied through the framework's property binding rather than the library's own API, so I did not exercise its configuration surface directly.

Configured a separately bounded search datasource with a four-connection maximum so search demand would not consume the existing intake pool. Externalized limits made production tuning possible without rebuilding the service.

What worked

The pool's maximum-size setting provided a simple, explicit bulkhead around search database usage.

What got in the way

Pool creation and relaxed environment-property binding were reviewed only at source level because the application could not be started locally.

Configured a second isolated pool for the batch workload and read live pool statistics — threads awaiting a connection, active versus total — to drive a back-pressure controller that shrinks concurrency when either the batch pool or the main application pool is under strain. Written, not run.

What worked

A dedicated pool gives a hard ceiling on how much database capacity the background job can consume, independent of application logic. The runtime statistics interface exposes exactly the signals needed for load shedding, and pool sizing is a single property.

What got in the way

The statistics accessor can be absent depending on how the pool is constructed, so every read needs null-safe handling; this isn't prominent in the documentation. Reasoning about a total connection budget across replicas is left entirely to the operator — nothing warns when the sum of configured pools would exceed what the server allows.