Serverless Cold Start
The additional latency when a function invocation must allocate and initialise a new execution environment rather than reusing a warm one.
The cost decomposes, and knowing which part dominates determines the fix. Platform allocation — provisioning the sandbox; largely out of your control. Runtime initialisation — starting the language runtime; a compiled language is dramatically faster here than a JVM or .NET runtime. Application initialisation — your own module imports, dependency injection, config fetches and connection setup, which is usually the largest and the only part you fully control.
Practical mitigations, in order of effectiveness: move work out of the init path (lazy-load what is not needed on every request), shrink the deployment package, choose a lighter runtime for latency-sensitive functions, and use provisioned concurrency where the platform offers it — which is really paying for warm capacity and therefore erodes the scale-to-zero economics.
The architectural consequence: cold starts hurt most at exactly the wrong moment — the morning ramp, a traffic spike, a scale-out event. A workload with a strict tail-latency requirement and spiky arrival is the case where serverless is hardest to make work.