performance-observabilityAnswer last reviewed July 2026

Logging feels like the most boring part of the stack, right up until it's your bottleneck. What makes logging hard at scale in Node, and why is pino designed the way it is?

A strong answer treats logging as a performance surface, structured output, async transport, sampling, and can say why pino is fast where a naive logger isn't

What an AI-prepared candidate might say

At scale logging becomes a performance and cost thing. Structured logging means emitting logs as JSON with fields instead of plain strings, which matters because you can query and filter by field in your log aggregation system, and you need that once the volume gets big. Plain string logs are hard to search and parse. Logging itself isn't free either, serializing objects and writing them costs CPU, and if the writes are synchronous or the destination is slow, it can block the event loop. Pino is the popular fast logger for Node. It does minimal work on the main thread, produces the JSON efficiently, and can push the writing and processing off to a separate transport or worker so it doesn't slow down request handling. At high volume you also sample, keep a fraction of the noisy high-frequency logs to control cost but keep the errors. So you get visibility without logging becoming the bottleneck.

Senior
Locked

Why unstructured logs stop being queryable at volume, what synchronous logging does to your event loop, and the design choices that keep pino cheap on the hot path.

Unlock the depth
Staff
Locked

How to keep logging off the hot path, sample high-volume logs without losing the ones you'll need, and the ugly failure where a slow log destination stalls the whole process.

Unlock the depth
Follow-up chain
Logging feels like the most boring part of the stack, right up until it's your bottleneck. What makes logging hard at scale in Node, and why is pino designed the way it is? | NodeBook