You're designing cost and capacity governance for an organization running dozens of serverless functions that share a single account-level concurrency limit and several downstream dependencies with their own capacity ceilings (e.g., a relational database, a rate-limited third-party API). What's your approach to preventing one function's traffic pattern from silently degrading cost or reliability for the rest of the account?

## The shared pool is a finite budget This is a governance problem sitting at the intersection of the shared-resource nature of serverless concurrency and the real cost and reliability **blast radius** that follows from it, so the approach has to operate at both the platform-configuration layer and the organizational-process layer simultaneously. Start from the fact that the account or region's total concurrency ceiling is a fixed, finite budget — treat it exactly like a shared physical resource in capacity planning, not an implementation detail each team is free to ignore. ## Classify every function, then size the reservations Classify every function along two axes: - **Criticality** — does throttling this function cause real user or business impact? - **Traffic predictability** — steady versus bursty versus driven by an upstream event source that can spike unpredictably, like a bucket receiving a bulk upload or a queue backlog draining all at once. From those two axes: - **Critical, low-predictability functions** get an explicit reserved concurrency **floor** sized against observed peak traffic with real headroom, not average traffic, so they're never starved by a noisy neighbor elsewhere in the account. - **Non-critical or clearly bursty, fan-out-prone functions** — batch processors, event-storm consumers, anything triggered by user-uploaded content — get an explicit reserved concurrency **ceiling** that deliberately caps their maximum draw on the shared pool, even if that means they queue or backpressure under extreme load; the goal is making their worst case bounded and predictable rather than 'as much as the account will give me.' - **The remaining unreserved pool** is kept with real headroom, not driven toward zero by over-reservation elsewhere, so newly deployed or lower-priority functions aren't throttled by default the moment they ship. ## Why this governance is necessary Why this governance is necessary at all: without it, a shared concurrency pool creates a classic multi-tenant blast-radius problem — one team's bug, such as an infinite retry loop, or one team's unplanned success, such as a feature going viral, can throttle every other function in the account, including ones entirely unrelated to the incident, simply because they all silently draw from the same finite pool. The identical logic applies downstream: a serverless function can scale out far faster than a traditional connection-pooled application server ever could, so an un-throttled burst of concurrent executions each opening a database connection can exhaust a connection-limited database in seconds, or blow through a third-party API's rate limit and get an account's API key temporarily banned — failures that concurrency limits inside the serverless platform alone don't prevent, because the platform's limit protects the platform's own capacity, not your specific downstream dependency's capacity. ## The trade-off, in both directions The trade-offs run in both directions, with cost named on each side. | Approach | What you get | The catch | |---|---|---| | **Aggressive reservation and capping** | protects reliability and bounds worst-case cost | but it costs engineering overhead — someone has to classify functions, size reservations against real observed traffic data, and revisit those numbers as traffic evolves — and it risks over-conservative caps causing self-inflicted throttling during a legitimate spike nobody anticipated | | **Looser, unmanaged concurrency** | avoids that governance overhead entirely | but it leaves both cost and reliability exposed to whatever any single function's worst day happens to look like, with no floor and no ceiling protecting anyone | ## Failure modes - **A marketing-triggered burst.** A concrete production failure mode: a marketing-triggered burst — a push notification, a viral post — drives a spike into a webhook-processing function with no reserved ceiling; it scales out to thousands of concurrent executions, each opening a connection to a shared relational database sized for a handful of long-lived application-server connections, and the database falls over, taking down every other service that depends on it, not just the function that spiked. - **A runaway recursive-invocation bug.** A separate failure mode, where a function republishes to the same queue that triggers it on error, consumes the entire account's unreserved concurrency pool within minutes, silently throttling unrelated production functions with no direct connection to the bug — and the on-call team initially has no idea why an unrelated payment function suddenly started failing, because the root cause is nowhere near the symptom. ## Where it shows up A concrete real-world mitigation pattern that addresses both governance layers at once: pairing serverless functions that talk to a relational database with a **connection-pooling proxy** layer, so that N concurrent function executions share a small, bounded pool of actual database connections instead of each opening its own, combined with a hard reserved-concurrency ceiling on that function sized to what the proxy and database can actually sustain under load testing — turning an unbounded fan-out risk into a deliberately bounded, tested one. That ceiling is then reviewed on a recurring cadence, whenever the database is resized or the function's traffic pattern materially changes, rather than being set once at launch and forgotten — governance, in this domain, is a **living configuration** tied to observed reality, not a one-time setup step.