Connection Pooling (HikariCP)
Reuse a bounded set of DB connections for throughput and stability.
📌 Key IdeaConnection pools amortize connect/auth overhead and cap DB concurrency. With HikariCP, sizing and timeout tuning matter more than exotic settings.
Why It Matters
- Database connections are expensive and limited; poor pooling causes immediate latency spikes.
- Pool configuration directly controls backpressure between app and database.
- Correct sizing avoids both request timeouts and DB thrashing.
Visual
?? DB connections are scarce resources
Requests -> [HikariCP pool] -> DB Too small pool -> queue/waits/timeouts Too large pool -> DB thrash/context switching
When to Use
- Any production JDBC app with repeated DB access.
- Need controlled DB concurrency and predictable latency.
- Need observability over wait times and saturation.
When NOT to Use
- Direct DB access is extremely infrequent (rare scripts).
- Pool size copied from internet without load testing.
Code Variations
1?? Hikari essentialsjava
HikariConfig cfg = new HikariConfig();
cfg.setJdbcUrl(url);
cfg.setMaximumPoolSize(20);
cfg.setMinimumIdle(5);
cfg.setConnectionTimeout(300);
cfg.setIdleTimeout(60000);Treat pool size as capacity control, not throughput magic knob.
Interview Q&A
Quick Cheat Sheet
GoalBound and reuse connections.
Key metricAcquire wait p95/p99.
SmellPool always maxed + request timeouts.