Serverless cold starts and how to mitigate them

WHAT THIS TESTS This checks your grasp of how serverless platforms actually run code, and why the very first request after a period of idle is noticeably slower, which signals whether you truly understand the execution-environment lifecycle.

A GOOD ANSWER COVERS A cold start is the latency incurred when the platform has no warm execution environment ready and must provision one: it allocates a sandbox, downloads your deployment package, bootstraps the language runtime, and runs your initialization code outside the handler. Only then does it invoke the handler. Subsequent requests reuse that warm environment and skip these steps, so they respond far faster. Mitigations include provisioned concurrency to keep a pool of environments pre-initialized, reducing package size so download and unpack are quick, choosing a lighter runtime since interpreted or VM-heavy runtimes initialize slower than compiled ones, moving expensive setup such as SDK clients and database connections into the init phase so they are reused across invocations, and scheduled warm-up calls for low-traffic functions. Because more memory also grants more CPU, raising memory can shorten initialization.

COMMON WRONG ANSWERS Describing every slow request as a cold start; most invocations are warm. Believing cold starts happen on every call. Claiming memory size has no effect on init. Ignoring that initialization code, not just package download, contributes to the delay.

LIKELY FOLLOW-UPS How does provisioned concurrency differ from reserved concurrency? Why do compiled runtimes start faster? Where should you create database clients? How does memory size affect cold-start duration?

ONE CONCRETE EXAMPLE A Java function with a heavy dependency tree takes two seconds on first call. Enabling provisioned concurrency keeps environments warm, trimming the package and lazy-loading clients reduces the cold-start tail, and steady-state warm calls then respond in tens of milliseconds instead of seconds, eliminating the user-visible latency spike on the first request after idle.