perf(admin-core): cap slave HikariCP pool

[shreyash-jain]

Summary

• Problem: admin_core_service slave (read-replica) DataSource pool was unconfigured in production. application-stage.properties (which sets spring.datasource.hikari.maximum-pool-size=5) is dead code because SPRING_PROFILES_ACTIVE=prod in prod and there is no application-prod.properties, so only the base application.properties applies. Additionally, the master-pool overrides there only bind to spring.datasource.hikari.* — the slave bean reads spring.datasource.read.hikari.* (see DataSourceConfiguration#slaveDataSource → @ConfigurationProperties("spring.datasource.read.hikari")).
• Effect: With nothing configured on the slave prefix, HikariCP falls back to its defaults (maximum-pool-size=10, minimum-idle=10) per replica. With 4 admin-core replicas that's 40 idle Postgres connections dedicated to the (lightly used) read replica — the single largest line item in the connection audit.
• Fix: Add spring.datasource.read.hikari.* overrides to the base application.properties. Cap maximum-pool-size=3, minimum-idle=0, and tighten idle-timeout/connection-timeout. Across 4 replicas this frees ~28 connection slots in the shared Postgres budget. Read throughput is unaffected today (replica handles negligible traffic).

Setting	Before (default)	After
maximum-pool-size	10	3
minimum-idle	10 (= max)	0
idle-timeout	600000 ms	30000 ms
max-lifetime	1800000 ms	600000 ms
connection-timeout	30000 ms	10000 ms

Per-replica savings: ~7 connections. With 4 replicas: ~28 connections freed.

Test plan

• Build passes (mvn clean install -DskipTests -pl admin_core_service -am)
• Deploy to stage; tail logs for HikariCP startup banner — confirm slave pool reports maximumPoolSize=3, minimumIdle=0
• On stage, exercise a known read-only endpoint (one that flips DataSourceContextHolder to SLAVE); verify queries succeed and no HikariPool ... Timeout failure errors
• After prod rollout, watch Postgres pg_stat_activity for application_name=admin_core_service connections from the read-replica host — should drop from ~40 to ~12 (3 × 4 replicas) max
• Watch admin-core p99 latency dashboards for 30 min post-rollout for regressions

[codacy-production]

Up to standards ✅

🟢 Issues 0 issues

Results:
0 new issues

View in Codacy

_{NEW Get contextual insights on your PRs based on Codacy's metrics, along with PR and Jira context, without leaving GitHub. Enable AI reviewer
TIP This summary will be updated as you push new changes.}