NOTE
Designing Resource Pools
A general model for thread, connection, object, and worker pools: lifecycle, sizing, queue bounds, validation, fairness, and overload behavior.
This is a historical learning note and may contain outdated or incomplete understanding.
1. Why Pool?
Pooling is useful when resource creation/destruction is expensive and reuse is safe.
Examples:
- database/TCP connections;
- worker threads;
- expensive reusable buffers/objects.
Pooling cheap objects can add contention and complexity with no benefit.
2. Core Parameters
Define:
- min/max resources;
- idle timeout/max lifetime;
- acquisition deadline;
- validation/replacement;
- waiting queue size/fairness.
3. Sizing
Bigger is not always better. A 1,000-connection pool can overwhelm a database that can execute only 100 useful concurrent queries.
Pool capacity should reflect downstream concurrency, latency, and desired queueing.
4. Overload
Never allow infinite waiting by default. Once the pool and bounded queue are full, reject/load-shed according to the caller’s deadline.
5. Health
Resources can become invalid while idle. Handle failure on use and retire unhealthy/old resources.
6. Metrics
Measure utilization, waiters/acquire latency, creation/destruction, timeout/reject rate, and downstream latency.