任務調度系統（Task Scheduler / Job Scheduler）這種東西，看起來每家公司都有，用起來都差不多，但只要你認真去看一次原始碼，就會發現每個團隊的取捨都不一樣。

這篇文章不是要告訴你「任務調度是什麼」。網路上的科普文已經太多了。我要講的是：當我們真的坐下來要畫一張架構圖，每一個節點為什麼要這樣選。參考的影片是 s09g 的《system design — 任務調度系統》(約 29 分鐘)，我把裡面 12 個章節的取捨整理成一條線，並加上我自己做後端這些年的看法。

我們的場景先講清楚：假設要替一個內部系統（10k 工程師規模）做一個任務調度平台。

支付系統設計：訂單、支付、對帳的一致性與冪等

這篇文章是看了 s09g 在 YouTube 上發的「system design — payment system」（19:47）之後的整理筆記。

我必須先承認一件事：我在寫金流的時候，第一次看這種題目也是先翻 Stripe 文件、把 SDK 串起來、看到 payment_intent.succeeded 就覺得「啊我會接金流了」。但 s09g 影片一開始就潑了一盆冷水——你沒有金融牌照，你拿什麼去划帳？

金流系統設計的本質，不是「怎麼呼叫 PSP」，而是「怎麼把一筆支付的事實記下來，並且保證它永遠對」。這才是後端工程師真正要扛...