The Memory Bomb
#infrastructure-critical — Exit Code 137
csv-export-api OOMKilled in 4 seconds. User exported 1.5M transactions — API loaded all rows into a JavaScript array, called JSON.stringify(), heap blew past the 512 MB cgroup limit. Linux SIGKILL. No stack trace.
The trap: buffer entire result set in RAM instead of streaming.
Your task
Rewrite `handleExportRequest()` in `export_server.js`: use `getTransactionStream()`, stream JSON row-by-row in chunks, keep memory flat.
Book: read file into memory · Prod: Streams + DB cursors survive any row count on 512MB.
Skills you'll prove
Interview Tip
When asked how you handle large file uploads/exports or prevent memory issues in Node.js, say: "In a containerized environment, memory is a hard constraint. If you load a massive file or a million database rows into memory using readFileSync or a standard SELECT *, you'll trigger the Linux OOM Killer and crash the pod with Exit Code 137. I solve this by using Streams (like fs.createReadStream or DB cursors) to process data in small chunks. This keeps the memory footprint constant and allows the app to handle gigabytes of data on a 512MB container."