前言

在上一篇文章中，我們成功將前端資源掛上 CDN，並透過 OAC 使得我們的 S3 物件資源被保護得好好的，而今天，我們從「請求的角度」出發，探討後端的 API 設計與 AWS Lambda 的角色，結合 Serverless 和 RESTful API，提升多人協作平台的可維護性與擴展性，順便聊聊鬆耦合架構，看看事件觸發的可能性。

所以 Lambda 到底是甚麼？

如同我們之前介紹的，Lambda 是一個 Serverless、Function as a Service (FaaS) 的服務，可以透過與 API Gateway 串接作為響應系統。

但當我們更深入一點時，Lambda 的幾個特性會成為我們做後端系統設計的重要依據：

無狀態 (Stateless)

• Lambda 作為 AWS 資源有著只依照執行時間計費的重大優勢，但它的缺點是無法保存狀態。
• 這意味著每次函數被觸發時，它都是一個全新的執行環境，上一個請求的資料不會自動保留。

自動擴展 (Auto-scaling)

• Lambda 可根據請求量自動調整執行實例數量，對於突發流量或高並發情境非常友好。
• 這也意味著後端服務設計必須是無狀態、可水平擴展，避免依賴單一執行實例。

適合事件驅動

• Lambda 天生適合處理事件驅動的工作流程，例如：
  • API Gateway 請求
  • S3 檔案上傳觸發

上述幾個特性讓 Lambda 變得很強，不過基於 Lambda 的後端系統也會有一些侷限性，例如無法長期記憶、需要拓展性導致的無法管理 Session 等

於是很多時候的 Context 即需要靠事件來帶入

我們系統中的「無狀態 (Stateless)」

而因此在系統中的實作，我們理所當然只能採用Stateless的設計哲學

舉個之前我們處理過的使用者管理為例子，透過 AWS Cognito，我們可以經 OAuth Flow 取得使用者識別 Token，再交給 API Gateway 依照請求來解析，如此一來 Lambda 完全不需要知道使用者有哪些，只需要解析請求所帶 Token 就好了，這就是 Stateless

RESTful API，無狀態 API 設計

在這種架構下，我們通常會搭配 RESTful API 來實現無狀態後端：

• 資源導向 (Resource-oriented)：每個 URI 代表一個資源，例如 /projects、/projects/{projectId}/events。
• HTTP 動詞 (Method) 對應 CRUD：GET 讀取資料、POST 新增、PUT/PATCH 更新、DELETE 刪除。
• 無狀態 (Stateless)：每個請求都攜帶完整資訊（例如 Authorization Header 或 Payload），後端不會保留上一次請求的狀態。
• 可快取 (Cacheable)：GET 請求可設計為可快取，提高效率。
• 統一介面 (Uniform Interface)：一致的 API 規範，讓前端與第三方都容易理解與整合。

透過 RESTful API + Lambda 的組合，我們能建構一個 雲原生、可水平擴展且易於維護的後端系統，同時保持無狀態與模組化。

需求切分，高可維護性系統

以我們的多人日曆共編平台為例，從使用者的請求出發我們大致上可以把需求分成三大塊

• 管理專案，新增/刪除專案，新增/刪除專案人員
• 管理事件，新增/刪除事件、決定行程的開始和結束時間
• 管理任務，新增/刪除任務、設定任務的到期日等等

那麼以後端架構而言，我們就可以這樣子設計:

依照需求劃分功能模組，一個 Lambda 管一件事，拆分得清清楚楚

設計架構時我們會希望盡量滿足以下幾個原則：

• PoLP（最小權限）：

  • Lambda 只授權存取其需要的資源，例如：

  (如果在多表設計的情境)

  • CreateEventLambda → 只可寫入 Events Table
  • DeleteProjectLambda → 只可刪除 Projects Table

• PoLR（最小責任）：

  • 每個元件只負責該做的事：
    • API Gateway → 驗證、授權與流量控制
    • Lambda → 業務邏輯處理
    • 資料庫 → 資料存取

這樣子設計出的元件相互依賴性不會過於混雜，系統若是需要大改就只需要局部更新，一個一個組件更新、上線，算是 Microservice( 微服務 ) 概念的基礎

鬆耦合架構

當業務邏輯複雜度上升時，例如我們要新增一個功能：任務快到期時自動提醒使用者，如果每個 Lambda 都直接呼叫其他 Lambda 或服務，程式碼會很快變得難以維護。

這時候可以採用 事件驅動(Even-Driven) + 鬆耦合 的方式：

1. Task Service 負責任務狀態管理
2. 當任務即將到期時，Task Service 發布一個事件，例如 TaskDueSoon
3. 其他 Lambda 來訂閱這個事件：
   • SNS：送出通知給使用者（也可用 SES / Lambda 直接呼叫 API）
   • UpdateStatsLambda：更新任務統計資料
4. 如果未來還想新增功能，例如同步到行事曆或第三方應用，只要訂閱 TaskDueSoon 就行，不會影響現有流程

簡單示意圖

AWS 服務提示：EventBridge 可做事件總線，SNS/SES 負責通知，Lambda 處理業務邏輯，保持每個元件只做自己的事（PoLR）。

如此一來在微運/系統更新上都可以享受鬆耦合的優勢，服務不必下線也可以增加新功能

結語

透過 Event-driven 架構，我們看見 Lambda 不只是單一的請求-回應邏輯，而是能在整個系統中，成為事件流中的一個組件。這樣的設計，讓我們的平台具備了更好的彈性與擴展性。

不過，當服務之間的互動越來越複雜，另一個問題隨之而來：我們要如何有效追蹤、監控並維護這樣的 Serverless 系統？

這將是我們在下一篇要深入探討的重點 —— Serverless 架構下的可觀測性 (Observability)，以及如何透過 AWS 提供的工具（如 CloudWatch、X-Ray）來確保系統在規模成長的同時，依然能保持穩定與透明。