My app generates large responses: CSV/JSON exports of user data, big report payloads, generated files. Right now these are built fully in memory (or fully buffered) and then sent, which gets slow and crashes for big accounts. Convert my large responses to streaming: 1. Find every endpoint that builds a large payload fully in memory before responding: exports assembled as one giant string, 'find all rows then serialize' patterns, files read wholly into memory then sent. 2. Convert data exports to stream row-by-row: query in batches or with a cursor, serialize each batch, and write it to the response as it arrives. For CSV, write the header row first, then rows as they're fetched. 3. Set the right headers early: content-type, content-disposition with a filename for downloads, and no content-length (or use chunked transfer) since the size isn't known up front. 4. Handle client disconnects: if the user closes the tab mid-export, stop the query and clean up instead of churning through 500,000 rows nobody will receive. 5. Handle failures mid-stream: once headers are sent I can't change the status code, so for exports that must succeed or fail atomically, generate to a temp location and redirect to a download instead. Tell me which endpoints need that treatment. 6. Verify memory behavior: memory usage during a large export should stay flat instead of climbing with result size. Don't stream endpoints that are small in practice; this is for genuinely large payloads. The deliverable is the converted endpoints, the disconnect and failure handling, and the before/after memory and time-to-first-byte measurements on my largest realistic dataset.