最近剛換到了新工作不久，新公司與前東家類似，有交易系統的業務存在：幫 user 建立訂單、加扣款、改狀態，核心邏輯圍繞著餘額在轉。
明明到了新的地方，加入了不同的團隊，但卻發現了一個幾乎一樣的 pattern：A、B、C 三個服務都在直接操作餘額表和訂單表，table 都沒有明確的歸屬，誰想操作就去操作。在前公司時每次看到這種架構都覺得哪裡不太對，在新公司看到一樣的 pattern 就更難忽視了。
本篇想從這個 pattern 出發，聊聊微服務架構下資料表的歸屬問題：同一個 table 到底該不該允許多個服務直接讀寫？以及如果只能透過 API 存取其他服務的資料表，如何解決跨服務一致性的問題。
公司目前的服務有幾隻API會提供用戶上傳檔案(KYC及回傳明細)用。而現有檔案上傳機制是將檔案以BLOB的形式存在資料庫的ATTACHMENT資料表內。
這種做法的好處是上傳檔案並且更改記錄狀態可以包成一包transaction，實現業務邏輯上資料的一致性(要嘛用戶的狀態為等待上傳並且屬於此用戶上傳的檔案還不存在、要嘛用戶的狀態為已上傳並且屬於此用戶上傳的檔案已歸檔)。
但是這樣做的壞處是DB那台機器對於操作下載檔案時會消耗一部分CPU與network io bandwidth，也就等於會拖慢DB處理關聯式資料CRUD的主業。隨著使用量的增加，團隊中最近開始考慮要將檔案上傳的功能拆出至DB以外的solution。
最近在看《軟體架構原理：工程方法》這本書，其中有一段講到身為架構師應該如何拿捏介入團隊實作的力道我覺得滿實用的。作者示範了兩種極端的架構師人格特質，以及列出幾項可以量化的點，透過這幾項量化後的分數加總決定應該施加多少介入的力道。
近期迴響