Edge Functions or Serverless Functions for Burst Traffic: Trade‑off Between Concurrency Limits and Latency

When designing a Netlify site that must handle sudden spikes in request volume, engineers need to pick between deploying the logic as an Edge Function or as a traditional Serverless Function. The decision hinges on how each platform’s concurrency limits affect latency when traffic exceeds the allowed simultaneous invocations.

Edge Functions are limited to 100 concurrent invocations per site; excess requests are queued at the edge, which can increase first‑byte latency until a slot frees. Serverless Functions run in a regional Lambda‑backed environment and are constrained by the account’s concurrent execution quota (default 100, adjustable via support); surpassing this quota typically results in HTTP 429 throttling rather than queuing. Because the latency impact of queuing versus throttling differs with request size, client geography, and burst duration, it is unclear which option yields consistently lower response times under sustained overload.

Which function type provides lower average latency when concurrent traffic regularly exceeds the 100‑invocation threshold? Does the geographic advantage of Edge Functions outweigh the queuing penalty compared to the regional latency and possible 429 responses of Serverless Functions under burst conditions?