客戶網站的訂閱與發文都走同一個雲端資料庫。上線沒多久，我們注意到一個規律：只要一段時間沒人操作，下一個寫入請求就會卡很久、甚至直接回 500。使用者按下「訂閱」，轉了快一分鐘，最後拿到一個錯誤——這是最不該出現在「轉換動作」上的體驗。

把後端日誌撈出來，畫面大概長這樣：

cannot connect to Postgres: Connection terminated due to connection timeout
Connection terminated unexpectedly
POST /subscribe 500 in 88s   # 使用者就這樣等了 88 秒

為什麼會這樣

Neon 這類 serverless Postgres 會在閒置後自動暫停來省資源。暫停後的第一個查詢要先把資料庫喚醒、重新建立連線，這段冷啟動可能要數十秒；而連線池裡原本握著的連線這時早已失效，直接拿來用就會噴連線錯誤。

所以這不是 bug，是 serverless 的本質。我們沒辦法消滅冷啟動，但可以讓它對使用者隱形。

解法：一層很薄的重試

我們加了一個包裝函式 withDbRetry()，把「取得連線＋這次查詢」整段包起來。重點只有三個：只重試連線類的暫時錯誤、用指數退避給資料庫醒來的時間、以及設一個嘗試上限讓最壞情況的延遲有界。

async function withDbRetry(fn) {
  for (let n = 1; n <= ATTEMPTS; n++) {
    try { return await fn(); }
    catch (err) {
      // 不是連線錯誤、或用完次數 → 立刻拋，不要硬撐
      if (!isTransientDbError(err) || n === ATTEMPTS) throw err;
      await sleep(BASE * 2 ** (n - 1)); // 0.5s → 1s → 2s
    }
  }
}

真正的眉角在這裡

重試很容易寫，但寫錯方向反而更糟。這幾條是我們在客戶站上實際踩過、才補起來的：

• 只重試「連線」錯誤。email 格式錯、unique 衝突、任何 4xx，都要立刻往上拋。重試它們不但沒用，還可能送出重複資料。
• 錯誤鏈要穿透。CMS 常把底層的 pg 錯誤包一層再丟出來，判斷是不是暫時性故障時，要往 err.cause / originalError 一路挖進去。
• 寄信別包進重試。SMTP 本來就慢，把它一起重試只會讓請求更久、更容易再逾時。我們讓寄信留在資料庫重試範圍之外。
• 冪等要顧。萬一連線是在 commit 之後才斷、重試又跑一次建立，得靠 unique 衝突被吸收成「已訂閱」，而不是變成 500 或重複寄出歡迎信。

這是我們在這個旅遊部落格客戶專案裡，一連串「serverless 很方便、但邊角要自己收」的其中一坑。之後幾篇會接著寫我們在同一個站上遇到的其他問題。