Different FaaS platforms manage instance concurrency differently - AWS Lambda by default routes exactly one invocation to an execution environment at a time, while Google Cloud Functions gen2 (built on Cloud Run) and Azure Functions can be configured to handle multiple concurrent invocations per instance. What are the practical implications of this difference for how you write handler code and size downstream connection pools?

## The design decision behind the difference FaaS platforms differ in a design decision that has outsized practical consequences: how many concurrent invocations a single running execution environment (instance) is allowed to handle at once. AWS Lambda's default and most common model is **single-concurrency-per-environment**: each environment processes exactly one invocation at a time, and when concurrent requests exceed the number of already-warm environments, Lambda's scheduler provisions additional environments (up to the account/function's concurrency limit) rather than routing a second concurrent request into an environment that's already busy. So if 100 requests hit a Lambda function simultaneously with only 5 warm environments available, Lambda cold-starts up to 95 more environments to cover the burst (subject to burst/scaling limits), and each of those 100 requests runs in complete isolation from every other one, in its own process, at the same moment. ## The concurrency-per-instance model Google Cloud Functions (2nd generation) is built on top of Cloud Run under the hood, and Cloud Run's model is fundamentally different: each instance is a container that can be configured, via a **concurrency setting**, to accept multiple simultaneous requests - up to 1000 per instance on Cloud Run, with a smaller default depending on the product. Azure Functions similarly allows concurrent execution within a single instance depending on the trigger type and hosting plan (the Consumption plan's HTTP trigger and various non-HTTP triggers process multiple invocations per instance by default, governed by settings like `maxConcurrentRequests` in `host.json`), and its Premium/Dedicated plans behave even more like traditional application servers. ## Thread-safety and shared mutable state This difference cascades into two very concrete practical implications for how you write code and size infrastructure. The first is thread-safety and shared mutable state. - **Under Lambda's one-at-a-time model**, your handler code never has to reason about two invocations executing concurrently inside the same process - even though module-scope state persists across invocations, it's only ever touched by one invocation's logic at any given instant, so a naive, non-thread-safe in-memory counter or cache is safe from race conditions (though still subject to the cross-invocation staleness issues that come with warm-state reuse). - **Under a concurrency-per-instance model** like Cloud Run-backed Cloud Functions or a multi-worker Azure Functions plan, two or more invocations can genuinely be executing your handler's code at the same moment inside the same process, meaning any shared mutable state - a global cache, a counter, a client object with internal mutable state that isn't documented as thread-safe - is a live race-condition risk that simply doesn't exist under Lambda's model, and you must actively write (or verify) thread-safe code, use language-level concurrency primitives (locks, concurrent collections), or explicitly avoid shared mutable state. ## Downstream resource sizing The second implication is downstream resource sizing, particularly database connection pools, and it points in the opposite direction. - **Under Lambda's model**, if you have N environments running concurrently, you effectively have N independent processes, each with (if you built one) its own connection pool - so a burst to 1,000 concurrent Lambda invocations, each holding even just 1-2 database connections, can slam a database with 1,000-2,000 simultaneous connections, frequently exceeding what a traditional relational database can handle (this is exactly why AWS built RDS Proxy - a connection-pooling proxy layer specifically to absorb this fan-out pattern from Lambda before it reaches the database). - **Under a concurrency-per-instance model**, far fewer total instances are needed to serve the same request volume (since each instance handles many requests concurrently), so a single shared connection pool per instance serves many concurrent requests, dramatically reducing the total connection count against the database for the same throughput - a genuine efficiency advantage of the shared-instance model, provided your pool is sized and your driver used correctly for concurrent access. ## The trade-off The trade-off, then, isn't that one model is strictly better: - **Lambda's isolation model** trades connection/resource efficiency for maximum safety and blast-radius containment (one invocation's bug, memory leak, or crash can never affect a concurrently-running sibling invocation, since they're in different processes). - **The shared-concurrency model** trades that isolation for resource efficiency and fewer cold starts under high fan-out (since fewer total instances are needed). ## A concrete real-world scenario A concrete real-world scenario: a team migrates an API from AWS Lambda to Google Cloud Functions gen2 for cost reasons and, without changing their handler code, starts seeing intermittent data corruption under load - because their handler had a module-scope, non-thread-safe cache object (safe under Lambda's one-at-a-time model) that was now being mutated by multiple concurrent invocations inside the same Cloud Run instance. The fix required either making that cache thread-safe (e.g., using a concurrent data structure with proper locking) or explicitly configuring the Cloud Run service's concurrency to 1 to replicate Lambda's isolation semantics, trading away the connection-pooling efficiency gain to restore correctness quickly while a proper thread-safe rewrite was scheduled.