Stop 08 · Serverless & Event-Driven ArchitectureTopics · 8/9

Cold Starts & Performance Considerations

In short

Your function answers in 40 ms, except sometimes it takes over a second. That occasional slow call is a cold start, and knowing where it comes from tells you how to shrink it.

The delay when a serverless function hasn't run recently and needs to initialize before handling a request — a real performance consideration for latency-sensitive applications, with several mitigation strategies.

At dawn the blob character lights a gas stove at a tea stall as a sleepy customer waits.

Think of it like this

The first chai of the morning

At 6 a.m. the stall owner has to light the stove, boil water and add tea before the first cup. That customer waits. Everyone after gets chai from the already-hot pot in seconds. The first cup is the cold start.

Watch it happen

What happens on a cold start

Fetch code

Sandbox

Boot runtime

Run init

Handler

1/5No warm copy exists, so the platform pulls your code package or container image.

The big ideas

What you need to know

Keep packages small

Fewer dependencies and tree-shaken bundles mean less to download and fewer modules to load.

Init once, reuse

Create SDK clients and DB connections outside the handler so warm calls reuse them.

Provisioned concurrency

Pay to keep a set number of copies initialised and ready. Cold starts vanish for that capacity.

Memory = CPU

In Lambda, more memory also gives more CPU, which can make init and work faster.

See it in code

Walk through the code

1import { DynamoDBClient, GetItemCommand } from "@aws-sdk/client-dynamodb";2 3// Runs once per cold start, then reused by warm calls4const db = new DynamoDBClient({});5const startedAt = Date.now();6 7export const handler = async (event) => {8  const res = await db.send(new GetItemCommand({9    TableName: "Orders",10    Key: { userId: { S: event.userId }, orderId: { S: event.orderId } },11  }));12  return { item: res.Item ?? null, copyAgeMs: Date.now() - startedAt };13};

1/4A small, specific import instead of a giant package.

Import only the client you need. Pulling in a whole SDK or a huge library makes every cold start slower.

Save yourself the pain

Common mistakes

Oops

Creating a new database client inside the handler on every call.

Do this instead

Create it once at the top level. Warm invocations reuse it for free.

Oops

Pinging the function every 5 minutes to "keep it warm".

Do this instead

That warms only one copy. For real guarantees under load, use provisioned concurrency.

Your mission

Measure your own cold start

~25 min

Quick check

Which change most directly reduces cold start time?

Go deeper

1Measure the response time difference between a 'cold' and a 'warm' function invocation.
2Learn mitigation strategies: provisioned concurrency, smaller deployment packages, and runtime choice.
3Understand why cold starts matter more for user-facing APIs than for background batch processing.