要用同步 API，還是改成事件處理？我會先從使用者的畫面想起：按下按鈕後，他需要立刻看到什麼？庫存查詢可能要馬上有答案，通知則可能晚幾分鐘也沒關係。先知道這個差別，再選做法。

本篇名詞小筆記

• REST API：依 REST 風格設計的 HTTP 介面，適合需要立即取得結果的同步操作。
• MQ：訊息佇列（Message Queue），讓送出端與處理端不必在同一時間完成工作。
• 冪等：同一項操作重複執行，最終仍只產生一次預期的業務效果。
• DLQ：死信佇列（Dead Letter Queue），用來存放無法順利傳遞或處理的訊息，等待人工接手。
• consumer lag：訊息已經進到 Queue，但還沒被 Consumer 處理，中間累積的等待量或延遲時間。

今天要解決的問題

如果使用者下一步一定要用到最終結果，就要把等待方式和完成時間設計好。如果先看到「已收到，處理中」就能繼續作業，後續工作就有非同步處理的空間。這個條件，應該先和使用單位確認。

上面四個問題，我會分開確認。有些步驟確實需要立即完成，但通知、索引更新或外部同步，不一定都要讓使用者一起等。把每一步的需要看清楚，才知道哪一段可以拆開。

架構師視角：切開「已接受」與「已完成」

例如，訂單請求可以先回覆已接受，再透過事件處理後續工作。但我會把「已接受」和「已完成」寫得很清楚，讓使用者知道，目前到底走到哪一步。

圖 Day 17-1：同步與非同步決策。

如果畫面只寫成功，使用者自然會以為全部完成，所以這份狀態也要一路做到畫面與資料模型。後面有哪個步驟失敗，也要有地方能查，才不會變成雙方認知不同。

所以，評估非同步時，我會一起算進狀態查詢的工作：目前進度、已完成的下游，以及失敗時誰處理。這些準備做好，使用者才有辦法安心等待結果。

工程師視角：事件欄位、冪等與同步契約

事件至少定義 eventId、eventType、occurredAt、aggregateId、schemaVersion、correlationId 與必要 payload。

事件欄位也各有用途。eventId 用來去重，schemaVersion 說明格式版本，correlationId 則把事件和原本的請求接起來。我會希望後面查問題時，仍能沿著這些資訊把整段過程找回來。

Consumer 必須做到冪等，失敗時有 retry 與 DLQ。冪等不是加上重試就會自然成立，Day 19 會說明實作方式。

呼叫端已經等不下去時，下游可能還在執行，這時要能查到操作狀態，避免一邊以為失敗，另一邊其實已經完成。所以同步 API 也要準備 timeout、錯誤契約與取消行為。

策略取捨與限制

非同步讓下游有時間慢慢完成工作，也多了狀態與一致性管理。同步比較容易順著流程理解，但如果一次請求要經過很多服務，各層等待與逾時就要一起安排。兩邊的準備工作，都算進去再決定。

驗證方式與衡量指標

畫面很快回應，是一項改善；業務最後多久才完成，則是另一件需要持續確認的事。所以我會把使用者等待時間和整段流程完成時間一起看。

今天先整理到這裡

一條流程裡，可以有需要立即完成的部分，也可以有稍後處理的工作。我認為最重要的，是讓每個回應和狀態都有清楚意思。下一篇，接著看看 Kafka 與 RabbitMQ 適合承接哪些需求。

參考資料

1. Apache Kafka, Apache Kafka Documentation，查閱日期：2026-09-30。
2. RabbitMQ, RabbitMQ Reliability Guide，查閱日期：2026-09-30。