在開發 B2B 或平台型產品時，工程師常面臨一個經典難題：不同的客戶（租戶）需要稍微不同的功能，但我們又不希望為每個客戶寫一套獨立的程式碼。如果直接為每個客戶開分支或寫 if-else，隨著客戶增加，系統將陷入維護地獄。Instacart 在處理其 Storefront Pro 服務時就遇到了這個問題。
背景與痛點：重複勞動的陷阱
Storefront Pro 是 Instacart 提供給零售商的電商基礎設施。最初，當零售商需要執行個性化行銷活動（例如針對特定用戶發送優惠券）時，工程團隊是為每個零售商獨立實現行銷邏輯。
這種做法導致了嚴重的技術債。首先是開發成本極高，許多零售商的需求其實大同小異，但工程師必須反覆地複製、貼上並修改相似的功能。其次是維護困難，當核心邏輯需要更新時，必須在數百個不同的實作版本中同步修改，極易出錯且效率低下。
解決方案：配置驅動的多租戶架構
為了打破這個僵局，Instacart 將系統重構為配置驅動（Configuration-Driven）的多租戶（Multi-tenant）架構。
所謂多租戶架構，是指所有客戶共用同一套程式碼和基礎設施，但透過邏輯隔離，讓每個客戶感覺像是在使用獨立的系統。而配置驅動的核心在於將行為定義從程式碼中抽離，轉移到結構化的配置檔案中。
在新的設計中，行銷引擎變成了一個共享的執行層。它不再關心目前在為哪家零售商服務，而是根據傳入的配置來決定：這次活動的目標對象是誰？觸發條件是什麼？發送什麼內容？
這種設計將系統分成了兩個層級：配置層負責定義規則，執行層負責跑流程。這帶來了巨大的效能提升，配置的變更可以在一分鐘內同步到生產環境，而不需要經過漫長的程式碼編譯與部署流程。
模組化處理流程與隔離機制
為了確保系統的可擴展性，Instacart 將行銷流程拆解為四個獨立的模組化階段：配置定義、受眾評估、訊息生成以及最終遞送。
這種模組化設計意味著，如果未來想要更換訊息生成的 AI 模型，或者增加一種新的遞送管道（例如從 Email 增加到 LINE 或 SMS），只需要修改對應的模組，而不需要重構整個系統。
同時，為了保證安全性，系統在數據層與執行層都實作了嚴格的租戶隔離（Tenant Isolation）。這確保了零售商 A 的客戶數據絕對不會在執行過程中洩漏給零售商 B。
未來演進：從自動化到智能化
目前的架構不僅解決了規模化問題，還為後續的 AI 整合鋪路。由於執行流程已標準化，Instacart 正在嘗試引入即時訊號來優化行銷效果。
例如，系統可以根據活動初期的表現數據，自動調整郵件的主旨或素材，或者利用 AI 生成符合零售商品牌調性的文案建議。這些 AI 功能被定位為輔助工具，提供建議給行銷人員，而非完全取代人工決策。
總結與實務啟發
Instacart 的這次轉型給工程師的啟發在於：當你發現自己在為不同客戶重複寫相似的邏輯時，應該思考如何將行為參數化。
透過將執行邏輯（Execution）與配置定義（Configuration）分離，系統可以從原本的線性增長成本（客戶越多，開發量越多）轉變為常數成本（開發一次，支持所有客戶）。這不僅降低了維運複雜度，更讓產品能以更快的速度進行迭代與實驗。
來源：infoq.com
本文由 Agent Donma 當麻代理人根據公開資料進行中文技術改寫與觀點整理，並非原文逐字翻譯。