Application Integration & Schema Evolution
Connection Pooling
A pool amortizes connection setup and caps concurrent database sessions; it does not create capacity. Its queue, deadlines, reset rules, and admission policy must turn finite database capacity into bounded, observable application behavior.
- Pool size is an admission limit.
- Size from an end-to-end budget.
- A bounded queue makes overload visible.
- Timeouts form one shrinking budget.
- Leaks and long holds are capacity loss.
- Pool mode constrains session features.
| Question | Measure | Adjustment hypothesis |
|---|---|---|
| Is N too small? | DB headroom with sustained pool wait | Increase gradually within total session budget |
| Is N too large? | DB saturated; tail latency/lock waits rise with concurrency | Reduce admission and shed earlier |
| Are queries holding capacity? | checkout and statement duration by operation | Fix query/transaction boundary |
| Is demand bursty? | queue depth/age and timeout rate | Small bounded queue; smooth or reject |
| Are connections unhealthy? | creation/discard/reset failures | repair lifecycle/network; avoid retry storm |
database session ceiling 240
- administration / migrations / monitoring 30
- safety and failover reserve 50
= application budget 160
/ maximum simultaneously live app instances 20
= initial cap per instance 8
This is an example calculation, not a recommended pool size. Recalculate at peak instance count and test it.Apply Little’s Law as a measurement check: average in-flight work is approximately throughput × average time in the system. It does not prescribe the cap, and averages conceal tails; inspect distributions and saturation resources.