Serverless cold starts and how to mitigate them
the serverless execution model.
a cold start is the latency to provision and initialize a fresh environment; mitigate with provisioned concurrency, smaller packages, and lighter runtimes.
calling every slow call cold.
What's really being asked
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.
The full answer
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.
The mistakes people make
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.
What usually comes next
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?
A 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.
Interview question
Which change most directly eliminates cold-start latency for a predictably high-traffic serverless endpoint?
- a.Adding a Dead-Letter Queue
- b.Switching the trigger from HTTP to a queue
- c.Enabling provisioned concurrency to keep initialized environments warmCorrect
- d.Increasing the function timeout
Why? this is the answer
Provisioned concurrency pre-initializes a pool of environments so requests skip provisioning. Increasing timeout, adding a DLQ, or changing the trigger affect failure handling and invocation style, not the cold-start initialization path.
Just read this? Test yourself on what you have been reading.
Read the original → docs.aws.amazon.com
- #serverless
- #lambda
- #performance
- #cold-start
- #latency
You just looked this up. Could you explain it out loud?
That is the part interviews actually test. Tezvyn takes questions like this one and gives you what the interviewer is really checking, the answer that lands, and the mistake that ends the conversation, in the four minutes before your next meeting.
The iPhone app is on the way
We are building it. Until it lands, nothing here is held back from you: every interview card, your saved cards, streaks and the job board all work in Safari, plus hundreds of free practice quizzes of thirty questions each. Sign in and it all carries over to the app the day it arrives.
Want it as an icon? Tap Share at the bottom of Safari, then Add to Home Screen. It opens full screen and the cards you have read stay available offline.
We are hiring for this. Open roles that interview on serverless — each one lists the topics its interview covers.
See open roles