最近剛換到了新工作不久，新公司與前東家類似，有交易系統的業務存在：幫 user 建立訂單、加扣款、改狀態，核心邏輯圍繞著餘額在轉。
明明到了新的地方，加入了不同的團隊，但卻發現了一個幾乎一樣的 pattern：A、B、C 三個服務都在直接操作餘額表和訂單表，table 都沒有明確的歸屬，誰想操作就去操作。在前公司時每次看到這種架構都覺得哪裡不太對，在新公司看到一樣的 pattern 就更難忽視了。
本篇想從這個 pattern 出發，聊聊微服務架構下資料表的歸屬問題：同一個 table 到底該不該允許多個服務直接讀寫？以及如果只能透過 API 存取其他服務的資料表，如何解決跨服務一致性的問題。
隨著 LLM 越來越成熟，近半年以來在公司開發業務邏輯幾乎都是用 vibe coding 的方式，下指令叫 AI 寫 code ，而自己只負責 review 及微調的模式進行。
vibe coding 這種開發模式真的又快又好用。以往以前要花三五天寫出來的功能，現在透過 AI 的協助大概半天就可以把功能做出來，然後再花半天 review、小調整，自己驗證測試確保所有細節都沒漏掉，基本上功能就是 production-ready 的 level 了。AI 問世後真的是軟體工程師的一大福音 XD。
本篇想分享這半年 vibe coding 以來，自己常用的一些下 prompt 的技巧，讓 AI 產出來的 code 盡量一次到位，避免品質時好時壞差異過大。
公司原本只有使用 OLTP 的資料庫，直到這一年來資料量越來越多導致報表類的 query 越查越慢。於是開始研究起 OLAP 的資料庫，希望可以把報表類的 query 拆出去，讓 OLTP 的資料庫專注在 OLTP 的業務上。於是今天要來分享最近在研究的 OLAP 資料庫叫 clickhouse，它有一種能做到平行運算的 distributed table engine，並且測試他在撈上億筆的資料的性能如何。
最近參與了有關區塊鏈相關的專案，系統內部的服務會去調 web3 的 API 做 ERC 或 TRC 的鏈路的 USDT 轉帳。實際下去開發後才發現在這兩個鏈路上創建交易的流程雖然有一些不一樣，但是卻都又能解決了重複交易的問題。因此趁著記憶猶新時寫了這篇：比較 ERC 與 TRC 的創建交易流程以及它們是怎麼防止同一筆交易被上鏈多次導致重複交易的。
在當前採用微服務的架構下想要對特定服務 debug 除了在本機將服務啟起來然後仿照其他服務打 API 請求過來外，也可以採用將本機的 debugger 連接至遠端服務進行遠端 debug 下斷點。
在 dev 環境與其他人串接流程找問題時我自己滿常用這招的，畢竟如果要在本地 debug 不太可能將整套微服務都啟一遍。
首先要允許 dev 遠端環境的服務被 debugger 連接的話，我們需要調整一下服務的啟動指令加入以下參數。
近期迴響