exactly-once 是謊言：前端工程師終於學會「冪等」
寫了很多年前端，「冪等（idempotent）」這個詞我當然看過——HTTP 規範裡有、面試題裡有。但我從來沒有意識到它：沒有在設計系統時把它當成一個要主動守住的性質。直到我的爬蟲系統經歷了一連串資料庫事故（覆盤見系列第二篇），我才發現整個系統能自癒的地基就是這兩個字，而且回頭一看——前端其實天天在用它，只是沒人告訴我它的名字。
#nodejs
2026
timeout 不等於 abort：一個資料庫 black-hole 殺死我爬蟲三次的覆盤
前情提要：我有一個 vibe coding 出來的台股行情爬蟲，跑在 Fly.io 上、資料庫用 Turso（libSQL，SQLite over HTTP）。上一篇〈讓 AI 全面 review 我 vibe code 出來的 production 專案〉提到，我做過一次全面 review、修掉 20 個問題。兩週後，它還是在盤中死掉了。
讓 AI 全面 review 我 vibe code 出來的 production 專案：20 個問題，其實只有兩種病
我有一個 side project：一個台股行情資料的爬蟲系統，每天開盤自動啟動、收盤停止、晚上全量重抓，跑在雲端、透過 Telegram 推播訊號。它是我一路 vibe coding 迭代出來的——功能一直長，但我從來沒有系統性地檢視過整個 codebase。它能跑，而且跑了好幾個月。
使用 Observer Pattern 重構複雜的資料上傳流程 - 以 PrimaryAPI 與 BackupService 整合為例
在後端開發中，我們常遇到需求不斷疊加，導致原本單純的類別（Class）變成了「上帝類別（God Class）」，職責混雜且難以測試。最近我在處理一個將資料上傳到 PrimaryAPI（主要資料平台）與 BackupService（備份服務）的功能時，就遇到了「堆疊式複雜度」的問題。本文將分享如何利用 Observer Pattern（觀察者模式）1 與 Mediator Pattern（中介者模式）2 來優化架構，達成高內聚低耦合的設計。