A library catalog Lambda is slow only on the first request after idle; later calls are fine. What latency pattern does that most strongly suggest?
Select an answer to reveal the explanation.
Short Explanation
First call after a nap is sluggish, then everything sings? That is classic cold start—warming the environment—not proof the algorithm got worse overnight.
Full Explanation
When a library catalog Lambda is slow only on the first request after idle and later calls are fine, that pattern most strongly suggests a cold start—environment initialization—rather than a steady-state algorithmic regression in the handler. Cold starts include runtime initialization, static client setup, and heavy imports; once warm, subsequent invokes reuse the environment, matching the "first request slow, then fine" civic symptom patrons notice after quiet periods on the catalog API.
A DynamoDB hot partition that appears only after the tenth identical query does not explain first-after-idle slowness. An ALB sticky-session misconfiguration is not required for typical API Gateway to Lambda invoke paths. A CodePipeline approval gate does not run inside each warm invocation and would not create this latency pattern.
Exam caveat: distinguish cold-start latency from sustained handler regressions; provisioned concurrency is one mitigation when cold starts violate citizen-facing SLOs on interactive catalog lookups.
Operational check: compare durations for cold versus warm invokes in CloudWatch and X-Ray, measure initialization versus invoke subsegments, reduce import-heavy code paths, consider provisioned concurrency for the catalog's latency-critical alias, and revalidate after idle periods.