Database Connection Pool Monitor Tile — Live Active/Idle/Waiting Breakdown

A connection pool's health isn't just "how full is it" — a pool sitting at 90% utilization with zero queued requests is fine; a pool with even one *waiting* request is actively causing latency for whoever is stuck behind it. This tile models that distinction directly: its health badge is computed from which specific condition is currently true, not from a single blended percentage.

Three distinct connection states, each visually and numerically tracked

The pool's connections are modeled as three separate counts — active (currently executing a query), idle (checked out but not currently in use, sitting ready), and waiting (a request that wants a connection but the pool is fully exhausted). The segmented bar renders one colored segment per state, sized proportionally to MAX_CONNECTIONS, so a glance at the bar's composition tells you not just how full the pool is, but *what kind* of full it is.

Health status logic checks waiting first, since it's the sharper signal

render()'s badge logic checks waiting > 0 before anything else — any waiting request at all immediately marks the pool "Saturated" (critical), because a nonzero wait queue means real requests are being actively delayed right now. Only if there's no queueing at all does the logic fall back to a softer check: whether total connections (active + idle) are at or above 85% of capacity, which is a "getting close" warning rather than an active problem. This ordering matters — checking utilization percentage first could mask a genuinely saturated-with-queued-requests pool that happens to still have a spare idle connection or two.

Simulated churn models realistic pool behavior, not just a random walk

tick() doesn't just nudge numbers up and down randomly — it models specific *events* a real pool experiences: a new query checking out a connection (active increases within capacity), a finished query returning its connection to idle, an unused idle connection being reaped, the pool filling up and a new request having to queue, and a queued request finally getting a freed connection. Each event has its own probability band and its own precondition (e.g. a connection can only be reaped if idle > 0), so the simulated numbers move in ways that resemble genuine pool dynamics rather than an unconstrained random walk that could, for instance, show waiting connections increasing while the pool has open capacity.

Clamping keeps every simulated value physically sensible

After every tick, active, idle, and waiting are all explicitly clamped — idle specifically clamped to MAX_CONNECTIONS - active, not just 0 to MAX_CONNECTIONS independently — so active + idle can never exceed the pool's real maximum capacity even if several probabilistic branches happened to push the numbers in the same direction in a short span.