Serverless: the developer focuses on function code; the platform (Lambda, Cloud Functions, Azure Functions) handles provisioning, scaling, and availability. There are still servers, but they are fully abstracted away.
2 / 5
What is a cold start in serverless functions?
Cold start: serverless platforms scale to zero between invocations. When a dormant function is invoked, the platform must provision a container, load the runtime and code, and run initialization code before handling the request — adding latency.
3 / 5
What are function execution limits and why do they matter?
Execution limits: AWS Lambda has a 15-minute timeout, memory up to 10 GB. Long-running processes, stateful workloads, or very large computations are ill-suited for serverless. These limits guide architecture decisions.
4 / 5
What is the event-driven programming model in serverless?
Event-driven serverless: a function is idle until an event arrives (API Gateway call, S3 upload, SQS message). This auto-scales naturally: 0 invocations → 0 cost; 10,000 events → 10,000 parallel invocations (within concurrency limits).
5 / 5
What is statelessness as it applies to serverless functions?
Stateless invocations: the execution environment may be reused or replaced between calls. Relying on in-memory state across invocations is unreliable. Persistent state must live in external stores (DynamoDB, Redis, S3), following the 12-factor app principles.