Connection Pooling and Keepalive

TechniqueNetworking and OSMidSeniorUpdated Nov 10, 2026

Reuse TCP and TLS connections across requests instead of opening a new one each time. Avoids the 3-way handshake plus TLS handshake on every call.

When to Use Connection Pooling and Keepalive

Any client making repeated calls to the same host. Without pooling, a Lambda hitting DynamoDB pays ~50ms of handshake per call; with pooling, subsequent calls are sub-millisecond setup.

In Practice

Node's http.Agent({ keepAlive: true }), Go's http.Transport (pooled by default), Java's HttpClient. AWS SDK v3 reuses HTTPS agents; v2 famously did not, which is why a lot of Lambdas paid hidden handshake tax.

Sketch

JavaScript

// Node.js: explicit keepAlive
const https = require("https");
const agent = new https.Agent({
  keepAlive: true,
  maxSockets: 50,
  keepAliveMsecs: 30_000,
});
fetch(url, { agent });

How Connection Pooling and Keepalive Comes Up in Interviews

Scenario

Your AWS Lambda calls DynamoDB and sees ~70ms p50 even though DynamoDB is sub-10ms. Each invocation opens a new HTTPS connection. Cheapest fix?

Move the SDK client to module scope and enable keepAlive so connections are reused across warm Lambda invocations. SDK v3 does this by default; v2 needed AWS_NODEJS_CONNECTION_REUSE_ENABLED=1.

The handshake tax is roughly TCP (1 RTT) + TLS (1-2 RTT). On cross-AZ paths that is easily 40-80ms before you ever send a query. Keepalive amortizes that across the container's lifetime.