How do you work out how many concurrent executions an AWS Lambda function needs, and what does Lambda do to a synchronous invocation once the account's concurrency limit is reached?

## Concurrency, not requests per second The question "how much Lambda do I need?" is not answered in requests per second, because Lambda does not meter capacity that way. One execution environment serves exactly one invocation at a time, so the quantity that matters is **how many are in flight simultaneously**. That is Little's Law: ``` concurrency = invocations per second x average duration in seconds ``` Work the examples until they're reflexive: - 100 rps, 50 ms average -> 100 x 0.05 = **5** concurrent executions. - 500 rps, 200 ms -> 500 x 0.2 = **100**. - 500 rps, 2 s -> 500 x 2 = **1,000** — same traffic, twenty times the capacity. - 10 rps, 60 s (a slow report generator) -> **600**, from traffic that looks trivial. The last two are the interviewer's point: **duration is a capacity multiplier**. A function that waits three seconds on a downstream call consumes concurrency for the whole wait, doing nothing. Removing that wait (or moving it off the request path) frees capacity in exact proportion. This formula gives the *average*. Real traffic is bursty, so provision against your peak and remember that duration is a distribution: if p99 is ten times the mean, your concurrency peaks are far above the average calculation. ## The account quota AWS enforces a per-Region, per-account limit on total concurrent executions summed across every function in that Region. The default is 1,000 and it is raisable through Service Quotas. You can read the current value from the API: ```bash aws lambda get-account-settings --query 'AccountLimit.ConcurrentExecutions' ``` Two things about this quota trip people up. It is **shared across all functions in the Region**, so a runaway batch function can consume the pool your latency-critical API depends on — the noisy-neighbour problem that reserved concurrency exists to solve. And it is **per Region**, so a multi-Region deployment has separate pools that must be raised separately. ## What throttling actually looks like When a new invocation would push concurrency past the applicable limit, Lambda does not queue it. It rejects it, and *how* you observe that depends entirely on the invocation path: - **Synchronous** (`RequestResponse`, an API Gateway or ALB integration, a direct `Invoke` call): the caller receives an HTTP **429** with the error type `TooManyRequestsException`. The client must decide whether to retry; the AWS SDKs retry throttling errors with exponential backoff by default, which can itself amplify the storm if the backoff is too aggressive. - **Asynchronous and event-source-driven** invocations are not surfaced to a caller — Lambda holds and retries them on its own schedule, so throttling shows up as *delay* rather than an error, which is why it often goes unnoticed until latency alarms fire. Either way the **`Throttles`** CloudWatch metric increments. It is the single most important Lambda metric to alarm on that most teams forget, because a throttled invocation produces **no** `Errors` datapoint and no function logs — from the function's own telemetry, the request simply never happened. ## Reading the right metrics - **`ConcurrentExecutions`** — the number in flight, sampled per minute. Compare its **Maximum** statistic against your quota; the Average will lie to you about spikes. - **`UnreservedConcurrentExecutions`** — how much of the account pool is left after every reserved allocation. - **`Throttles`** — rejections. Any non-zero value on a user-facing function deserves an alarm. - **`Duration`** — the other half of the formula; a regression here silently raises your concurrency needs. ## Designing with the number Once you can compute concurrency, several design decisions become arithmetic rather than intuition. Sizing the headroom you need before a launch. Deciding whether a synchronous API can absorb a spike or needs a queue in front to convert a burst of requests into a bounded stream of work. Predicting the load your function will put on a downstream database, since peak connections track peak concurrency, not request rate. And, in the other direction, understanding that a quota increase is not a fix for a function whose duration has quietly tripled — that is a capacity leak, and the formula tells you where it went.