Skip to content

How would you decide whether Lambda cold starts need fixing?

1 min read · main part only; folded sections are optional

After this you can answer: How would you decide whether Lambda cold starts need fixing?

A cold start creates a new execution environment and initializes module-level code. Reused environments skip that initialization, but reuse is not guaranteed. MiniTickets constructs DynamoDB, SQS and mailer dependencies at module scope. Per-invocation IDs and message state still belong inside the handler.

Inspect Lambda REPORT lines alongside queue age and end-to-end completion timestamps. A large initialization value with a short warm handler suggests a different problem from every batch spending seconds on SES. The ticket worker also performs QR rendering and fetches its signing secret lazily, so compare equivalent work rather than mixing the two functions.

AWS’s execution-environment documentation describes initialization and reuse. Memory tuning, smaller imports and provisioned concurrency are options to measure. Current infrastructure does not configure provisioned concurrency. No production cold-start percentile or acceptable customer delay is established by this repository; those require a workload and a service objective.

Can a warm process keep customer data globally?
Avoid per-request mutable state at module scope. Reuse clients and intentionally cached configuration, not a customer payload or authorization context.
Would a scheduled warm-up guarantee no cold starts?
No. New capacity and replaced environments can still initialize. It is not a latency guarantee.
When would provisioned concurrency be justified?
When a measured latency objective warrants its standing cost and the configured capacity covers the expected demand.

Read the path chapter, select the relevant map piece →, then inspect apps/worker/src/lambda.ts → handler. Work through the related case for a diagnostic example.

Read this book online: https://book.theversehub.in/