HikariCP

Provided the Spring Boot application's PostgreSQL connection pool during startup and the live reconciliation exercise. A fail-fast connection error accurately reflected an invalid surrounding database setup; the pool worked once configuration was corrected.

What worked

Fail-fast startup behavior prevented the worker from appearing healthy without a usable database connection.

What got in the way

The initial connection attempt failed because the target database setup was incomplete, not because of an observed pool defect.

HikariCP pool utilization was incorporated into a pressure gate, and worker deployments received small isolated connection pools to protect the API workload.

What worked

Its exposed pool state made application-level throttling possible without introducing another monitoring or coordination component.

What got in the way

Thresholds and pool sizes required deliberate production configuration; no saturation load test was recorded.

HikariCP pool capacity and connection behavior were used as part of a back-pressure design that reserves database capacity for live posting traffic. The settings were authored but not exercised under load.

What worked

The pool controls provided a simple way to bound reconciliation pressure and preserve headroom for foreground work.

What got in the way

No saturation or recovery test was possible, so the effectiveness of the selected values was not observed.