Cold starts in serverless environments

WHAT THIS TESTS This probes your understanding of how serverless and scale-to-zero platforms actually execute code and why latency is bimodal between warm and cold invocations.

A GOOD ANSWER COVERS Serverless platforms and auto-scaling PaaS scale instances on demand, sometimes down to zero. A cold start is the latency incurred when a request arrives and no warm instance is available to serve it. The platform must allocate and start a new execution environment: provision a container or microVM, load the language runtime, download and unpack your code and dependencies, and run your one-time initialization such as opening database connections or loading models, before your handler runs. All of that happens before the first response, so the affected request sees added latency, while subsequent requests reusing the warm instance are fast. The cost scales with package size, runtime, and how much init work you do. Mitigations include keeping instances warm with provisioned concurrency or a minimum-instance setting, or scheduled pings, and reducing init cost by shrinking the deployment package, lazy-loading heavy dependencies, choosing a faster-starting runtime, and moving work out of the global init path.

COMMON WRONG ANSWERS Confusing cold start with normal network latency or steady-state execution time. Saying it affects every request equally. Claiming more memory alone always fixes it, ignoring init and package size. Thinking scale-to-zero has no downside.

LIKELY FOLLOW-UPS Why do heavier runtimes like the JVM or large dependency trees worsen cold starts? What is the cost tradeoff of provisioned concurrency? How does VPC attachment historically affect cold starts? How do you measure cold versus warm latency?

ONE CONCRETE EXAMPLE A Lambda packaged with a large machine-learning library scaled to zero overnight. The first morning request waits while AWS provisions a container, loads the Python runtime, unpacks hundreds of megabytes of dependencies, and imports the model, adding seconds of latency. The team enables provisioned concurrency to keep two instances warm for peak hours and lazy-loads the model only when needed, cutting the user-visible cold-start delay dramatically.