Cold Start at the Edge
The initialisation delay when a request reaches a location with no warm instance, which at the edge occurs far more often because traffic is spread across many locations.
The same total traffic distributed across two hundred edge locations means each location sees a fraction, so instances are far more frequently cold than in a regional deployment. Cold start is therefore not an occasional tail case at the edge; for low-traffic applications it is the common path.
This is why edge runtimes are built the way they are. Lightweight isolate-based runtimes start in single-digit milliseconds rather than the hundreds a container takes, which is what makes edge execution viable at all — and the cost of that choice is the constrained runtime: a restricted API surface, limited execution time, tight memory, no persistent local state, and often no arbitrary native code.
Those constraints determine what belongs at the edge. Request routing, header manipulation, authentication checks, redirects, personalisation on a small attribute set, and response transformation all fit. Anything needing a database connection pool, substantial computation, large dependencies or local state does not, and pushing it there produces worse latency than leaving it at origin because every invocation pays initialisation plus a call back to the data anyway.