v8-memoryAnswer last reviewed July 2026

Your service calls JSON.parse on a 100MB response body. What actually happens, in memory terms and in latency terms?

A strong candidate prices a big `JSON.parse` across loop time, allocation spike, and string representation, then designs the payload path around all three

What an AI-prepared candidate might say

So JSON.parse is synchronous, which means parsing 100MB blocks the event loop for however long the parse takes, easily hundreds of milliseconds I'd guess, and no other request gets served during that window. And you pay for the memory more than once. The raw body arrives as Buffers, that gets converted to a JavaScript string, and then the parsed object graph gets built on top, which together can reach several hundred megabytes for a 100MB payload. That allocation burst also forces extra garbage collection work, so more pauses. The usual mitigations are limiting payload sizes, paginating the API so responses stay small, or using a streaming JSON parser that processes the document incrementally instead of holding all of it at once. And for services that really have to handle large payloads, moving the parse off the main thread with a worker thread is an option.

Senior
Locked

The three-stage bill for buffer-to-string decode, the synchronous parse, and the object-graph blowup, plus the string internals (ropes, sliced strings) behind surprise retention.

Unlock the depth
Staff
Locked

Why the worker-thread instinct mostly fails here, the protocol-level fixes that actually hold up, and the ingress caps that make a 100MB body impossible by design.

Unlock the depth
Follow-up chain
Your service calls JSON.parse on a 100MB response body. What actually happens, in memory terms and in latency terms? | NodeBook