在使用生成式 AI 推進 Push 通知功能設計時，我注意到了一個在效能面上令人介意的架構。
從設計上來看，處理 1 位通知對象時，最多可能對 DB 查詢約 11 次。
通知對象 DB 查詢1 人約 11 次100 人約 1,100 次1,000 人約 11,000 次這次不是在說正式環境發生了障礙，而是在設計階段就發現問題並重新檢討的故事。
1,000 人就 11,000 次。問題在哪裡？
對 DB 的查詢，不只是單純計算一次而已。
會發生應用程式向 DB 發出查詢、DB 搜尋資料、再回傳結果這樣的互動。
例如，假設要在公家機關確認 1,000 人的資料。
原本只要
請幫我一次整理這 1,000 人的資料
就能完成，卻變成每 1 個人都要跑 11 次櫃檯確認的感覺。
如果是 1,000 人，那就是 11,000 次往返。
雖然電腦或伺服器不會立刻壞掉，但 DB 的通訊、查詢、連線等待會增加，甚至可能讓其他 API 的處理也變慢。
檢視設計時讓我在意的點
在確認送來的設計內容時，我在意的是，針對每位對象的處理中，DB 存取重複出現了好幾次。
每一個處理本身都很自然。
確認通知對象
確認通知條件
取得裝置資訊
確認是否已通知
保存結果但是，如果對每位對象都重複執行這些步驟，
每人約 11 次 × 對象人數DB 查詢次數就會這樣增加。
因此我把人數乘上去一算，發現 100 人約 1,100 次、1,000 人約 11,000 次，於是決定重新檢討設計。
即使一個一個發送通知，也不需要一個一個去查 DB
Push 通知本身，確實需要針對每位對象分別發送。
但是，通知所需的資訊不需要每次都去 DB 重新取得。
例如可以設計成：
先從 DB 一次取得所需資訊
↓
再針對對象逐一發送 Push 通知
↓
最後將結果彙總寫回 DB重點不在於 SQL 一定要寫幾條，而是：
避免出現「對象人數增加 10 倍，DB 查詢次數也跟著增加 10 倍」的架構
使用 AI 做設計時的感想
這次的設計並不是「因為 AI 所以出錯」的故事。
就算是人類自行設計，也同樣可能發生這種問題。
只是，使用生成式 AI 時，從設計到實作的速度會非常快。
因此不能只確認：
能不能動
就直接往下走，還需要另外檢查：
如果是 100 人呢？
如果是 1,000 人呢？
SQL 會發出幾次？
有沒有在迴圈內存取 DB？
我也覺得，讓 AI 不只負責實作，而是
請只針對效能面進行審核
來做 review，會很有效。
總結
這次在 Push 通知功能的設計階段，
發現了每位對象最多可能產生約 11 次 DB 查詢的架構
。
這次學到的事很簡單：
「能正確運作」和「使用者增加後仍能承受」是兩回事。
使用 AI 可以提升開發速度。
也因此，在設計完成後，最好再確認一次：
「如果規模變成 100 倍會怎樣？」
我認為這件事比以往更加重要。
1) --- 會變成分隔線（上一行必須是空白）
2) # 會變成一級標題
3) ## 會變成二級標題
4) ### 會變成三級標題
5) **粗體文字**會顯示粗體文字
6) ```當第一行與最後一行會顯示程式碼
7) 請搜尋 Markdown 語法，了解各種格式
