想像一個查詢要一次回傳幾萬筆資料，最直覺的寫法是：查完整個結果集 → 組成一包 JSON → 一次回給前端。資料少的時候完全沒問題，但只要資料一多，就會冒出一個很惱人的體驗問題：

API 的 latency 會隨著資料量線性升高，而使用者只能盯著 loading 乾等。

因為在「查完 + 組完 + 傳完」之前，前端什麼都拿不到，使用者等的是「最後一筆資料也準備好」的那一刻 — — 即使部分資料早在幾百毫秒前，就已經可以從資料庫拿到，使用者還是得等到最後。

為了解決等待的痛點，把傳統一口氣給所有資料的 API ，改成持續輸送資料的 Streaming 方式，是本篇文章的重點。

原本的流程

做法很典型：

1. 透過 RDS Data API 對 Aurora 下 SELECT * FROM ad_clicks WHERE ad_id = …
2. 把整個結果一次撈回 Lambda 記憶體
3. 在 Lambda 裡組成一包 JSON
4. 透過 API Gateway 一次回傳

除了 Latency 之外，也有其他的限制，像是 RDS Data API 、API Gateway 和 Lambda 本身回覆的 response size 都有上限，這也是當前架構的上限。