Concurrent requests on warm functions


Four concurrent requests multiplexed onto one warm function invoke
Concurrent Functions can multiplex multiple requests onto a warm function instance, so bursts reuse capacity instead of cold-starting a new execution environment for every arrival.
How request multiplexing works
While a runtime is warm, Easel can route additional concurrent requests to it within safe limits. Shared process caches stay available across those requests, which cuts cold starts during traffic spikes.
Each request still gets its own identity and auth context. Shared infrastructure must not leak tenant state between concurrent handlers.
What you should notice
Burst traffic that used to fan out into many cold starts now often lands on warm instances. Watch concurrency and duration in Observability after Concurrent Functions are active on a project.
Design handlers to be safe under concurrency: avoid mutable globals for user identity, and keep per-request state on the request fork. Platform primitives favor process reuse with request-local binding.