A token bucket bounds admitted work while allowing accumulated credit to be spent in a burst. It does not automatically space requests evenly, guarantee completed throughput, or cap the number of operations still running. Those are separate scheduling and capacity questions. The bucket’s two parameters describe a budget, not a promise that the service can perform it. ...
Least-connections balancing chooses a peer using active connection counts, with the implementation’s weighting and tie rules. In nginx, least_conn accounts for server weights and uses weighted round robin among equally suitable peers. This can help when requests occupy connections for different durations. It is still a connection-based measurement, not direct knowledge of CPU, memory pressure, queued jobs, or database contention. ...
A pool leak is an ownership failure: application work finishes, but its borrowed connection remains checked out. The database may still answer other clients normally while this application has no leases left. Treat release as part of the operation’s contract, including exceptions and early returns, rather than a cleanup courtesy after success. ...
A Kubernetes resource request and a resource limit belong to different decisions. Requests participate in scheduling and resource sharing; limits configure execution constraints supported by the runtime and operating system. Treating a limit as the scheduler’s reservation obscures both mechanisms. A useful resource policy identifies placement needs, acceptable contention and the failure behavior when a running workload reaches its boundary. ...
Capacity planning turns a demand forecast into a provisioned operating envelope. The useful question is not how many requests a machine can accept before crashing, but what workload the service can sustain while meeting its latency and correctness requirements. That answer depends on request cost, dependencies, and failure assumptions. A spreadsheet becomes useful when each of those assumptions has a source and an owner. ...
A connection cap limits one owner’s demand; it does not automatically cap every application sharing a database. The useful budget is the sum of physical connections that can reach each backend, including idle pooled connections. Begin with the backend’s usable slots, then allocate them across all callers and deployment states. ...