<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
  <channel>
    <title>Tech Hub</title>
    <link>https://www.10410491.xyz</link>
    <atom:link href="https://www.10410491.xyz/feed.xml" rel="self" type="application/rss+xml" />
    <description>後端工程師 Leo Wu 的第一手技術與生活文章：Go、金流、高併發、系統設計。</description>
    <language>zh-Hant</language>
    <lastBuildDate>Sat, 27 Jun 2026 10:00:00 GMT</lastBuildDate>
    <item>
      <title>我把 300 行 if-else 拆成狀態機，然後後悔了一半</title>
      <link>https://www.10410491.xyz/blog/refactor-ifelse-to-state-machine-regret</link>
      <guid isPermaLink="true">https://www.10410491.xyz/blog/refactor-ifelse-to-state-machine-regret</guid>
      <pubDate>Sat, 27 Jun 2026 10:00:00 GMT</pubDate>
      <category>Programming</category>
      <description>這篇沒有什麼驚心動魄的線上事故，就是一個關於「過度設計」的自我檢討。我把一段醜到不行的訂單狀態判斷——大概三百行的巢狀 if-else——重構成了一台漂亮的狀態機。同事都說好看。半年後我回頭看，一半覺得值得，一半覺得我當初想太多。這篇講我為什麼重構、為什麼後悔了一半，以及我現在怎麼判斷「這個東西到底該不該上狀態機」。 一開始那段程式碼有多糟 訂單有十幾種狀態：待付款、已付款、備貨中、已出貨、已完成…</description>
    </item>
    <item>
      <title>一次半夜的 NTP 校時，讓我的訂單編號撞號了</title>
      <link>https://www.10410491.xyz/blog/snowflake-id-clock-drift-incident</link>
      <guid isPermaLink="true">https://www.10410491.xyz/blog/snowflake-id-clock-drift-incident</guid>
      <pubDate>Fri, 26 Jun 2026 10:00:00 GMT</pubDate>
      <category>System Design</category>
      <description>凌晨三點多，值班手機響了。對帳服務噴出一堆「主鍵衝突」的錯誤——有兩筆完全不同的訂單，拿到了一模一樣的訂單編號。我們的訂單 ID 是用 Snowflake 演算法自己產的，理論上全域唯一、絕不重複。結果它重複了。這篇覆盤那晚到底發生什麼事，以及「時鐘」這個我們平常最不會去懷疑的東西，怎麼一口氣把一套設計良好的分散式 ID 打穿。 先簡單說 Snowflake 怎麼保證唯一 Snowflake 產生…</description>
    </item>
    <item>
      <title>使用者早就關掉頁面了，我的資料庫卻還在幫他跑查詢</title>
      <link>https://www.10410491.xyz/blog/go-context-cancellation-propagation</link>
      <guid isPermaLink="true">https://www.10410491.xyz/blog/go-context-cancellation-propagation</guid>
      <pubDate>Wed, 24 Jun 2026 10:00:00 GMT</pubDate>
      <category>Backend Engineering</category>
      <description>有一次線上 DB 的 CPU 莫名其妙飆到 90%，但 QPS 沒有暴增，慢查詢日誌也沒特別多。我查了快一個小時才發現真正的兇手：一堆「使用者早就取消、但後端還在跑」的查詢。前端請求逾時、使用者關了分頁，連線斷了，可是我的 Go 服務完全不知道，還老老實實地把一個要跑 8 秒的報表查詢跑完，然後把結果寫進一個沒人在聽的連線裡。這篇講 context.Context 的取消到底怎麼傳、我漏在哪一層，…</description>
    </item>
    <item>
      <title>坐在桌子兩邊：我當面試官，也當求職者，學到的那些事</title>
      <link>https://www.10410491.xyz/blog/tech-interview-both-sides</link>
      <guid isPermaLink="true">https://www.10410491.xyz/blog/tech-interview-both-sides</guid>
      <pubDate>Thu, 18 Jun 2026 12:00:00 GMT</pubDate>
      <category>生活</category>
      <description>我換過幾次工作，也以面試官的身分面過大概兩三百個人。有一陣子，我幾乎每週都要花掉好幾個下午坐在會議室裡，看著對面那個緊張到把履歷捏出摺痕的人，心裡盤算著「我願不願意每天跟這個人一起 debug」。後來自己又出去面試，坐到桌子的另一邊，被別人這樣盤算。 這兩個角色我都待過夠久，久到足以推翻一些我年輕時深信不疑的東西。今天想把這些事好好講一講，不是教你怎麼通過面試的攻略文，而是我真心覺得，如果早幾年有…</description>
    </item>
    <item>
      <title>我曾經是那種把人講跑的工程師：談談工程師怎麼跟不懂技術的人溝通</title>
      <link>https://www.10410491.xyz/blog/engineer-communicating-with-non-tech</link>
      <guid isPermaLink="true">https://www.10410491.xyz/blog/engineer-communicating-with-non-tech</guid>
      <pubDate>Thu, 18 Jun 2026 11:00:00 GMT</pubDate>
      <category>生活</category>
      <description>我以前真的把人講跑過 我講一件不太光彩的事。 大概是我入行第四、五年的時候，技術上自認小有底氣，做過撮合引擎的核心，扛過幾次大流量。有一次公司要上一個新功能，PM 來找我估時間，順便問我為什麼前一個版本會卡。我記得我滔滔不絕講了快二十分鐘，從資料庫的鎖講到我們的訂單佇列，講到 Redis 的某個資料結構，講到 GC，講到我覺得某段程式碼寫得很爛應該重構。我講得很爽，覺得自己把事情講得很清楚。 那個…</description>
    </item>
    <item>
      <title>工程師怎麼持續學習：我追新技術追到很累之後，學會的事</title>
      <link>https://www.10410491.xyz/blog/how-engineers-keep-learning</link>
      <guid isPermaLink="true">https://www.10410491.xyz/blog/how-engineers-keep-learning</guid>
      <pubDate>Thu, 18 Jun 2026 10:00:00 GMT</pubDate>
      <category>生活</category>
      <description>我寫程式快十五年了。這段時間裡，我看著 jQuery 從神壇上跌下來，看著 AngularJS 整碗砸掉重練變成 Angular，看著 React 從一個臉書內部專案變成半個前端世界的共主，看著容器化、微服務、Serverless、然後是現在每天都有人在講的 AI Agent。每一波我都或多或少跟過。 而我想先誠實講一件事：我曾經被這些東西追到很累。 那種焦慮是真的 我記得有一段時間，大概是我做交…</description>
    </item>
    <item>
      <title>資料庫連線池調校：我踩過的連線數地雷</title>
      <link>https://www.10410491.xyz/blog/database-connection-pool-tuning</link>
      <guid isPermaLink="true">https://www.10410491.xyz/blog/database-connection-pool-tuning</guid>
      <pubDate>Wed, 17 Jun 2026 16:00:00 GMT</pubDate>
      <category>Database</category>
      <description>從一次搶購事故說起 那是一個很普通的週四晚上八點。我們在做一檔限量商品的搶購活動，行銷估計大概會有幾萬人同時湧進來。後端服務早就壓測過了，DB 也升級到更高規格，我心想應該穩。 結果開賣後不到三十秒，監控就開始噴錯。不是 DB 掛掉，也不是 CPU 燒滿，而是大量的請求卡在一個我當下沒立刻反應過來的地方：等待資料庫連線。應用程式的 log 裡塞滿了「connection pool exhauste…</description>
    </item>
    <item>
      <title>一次 rename 欄位跟程式一起上線，把正式站打成一片 500——不停機改 schema 的完整流程</title>
      <link>https://www.10410491.xyz/blog/zero-downtime-schema-migration</link>
      <guid isPermaLink="true">https://www.10410491.xyz/blog/zero-downtime-schema-migration</guid>
      <pubDate>Wed, 17 Jun 2026 15:00:00 GMT</pubDate>
      <category>DevOps</category>
      <description>一次「應該很安全」的改名 那次我很有信心，結果翻車翻得很難看。 需求只是把一個欄位改個更清楚的名字。我在一個 migration 裡把欄位 rename 了，程式碼也同步改成用新名字，兩個一起打包上線。在我的認知裡這很乾淨——舊名字沒人用了，改掉剛好。 問題是，正式環境的部署不是一瞬間完成的。新版程式在滾動更新，一部分機器已經是新版（用新欄位名），一部分還是舊版（用舊欄位名）。而資料庫的 rena…</description>
    </item>
    <item>
      <title>分散式鎖的正確實作：Redis 鎖與我看過的那些災難</title>
      <link>https://www.10410491.xyz/blog/distributed-lock-redis</link>
      <guid isPermaLink="true">https://www.10410491.xyz/blog/distributed-lock-redis</guid>
      <pubDate>Wed, 17 Jun 2026 14:00:00 GMT</pubDate>
      <category>Backend Engineering</category>
      <description>做後端做久了，你會發現有一類 bug 特別陰險：平常都好好的，壓力測試也過了，上線跑了三個月相安無事，結果某天半夜流量一尖峰，帳就對不上了。客訴進來說「我明明只點了一次提現，怎麼被扣兩次」，或是行銷活動的限量券被同一個人搶了五張。你翻 log 翻到天亮，最後發現問題出在一個你以為早就處理好的地方——並發控制。 在單機時代，這種問題用一把行程內的鎖就解決了。Go 裡面一個 sync.Mutex，Ja…</description>
    </item>
    <item>
      <title>資料庫交易隔離等級：髒讀、不可重複讀、幻讀的實戰</title>
      <link>https://www.10410491.xyz/blog/db-transaction-isolation-levels</link>
      <guid isPermaLink="true">https://www.10410491.xyz/blog/db-transaction-isolation-levels</guid>
      <pubDate>Wed, 17 Jun 2026 13:00:00 GMT</pubDate>
      <category>Database</category>
      <description>做交易所撮合跟金流這幾年，我修過最痛、最難重現的 bug，幾乎都跟交易隔離等級脫不了關係。這類 bug 有個共通特性：在你電腦上跑單測都對、在 staging 也對、QA 點一整天也對，結果一上線，併發量一上來，餘額對不上、庫存超賣、對帳差幾塊錢。然後你看 log 看到天亮，因為它根本不是程式邏輯錯，是你對資料庫在併發下的行為有錯誤的假設。 這篇我想把隔離等級這件事講清楚。不是背定義，而是用我實際…</description>
    </item>
    <item>
      <title>我們一開始選了 Kafka，結果殺雞用了牛刀——訊息佇列選型的真實復盤</title>
      <link>https://www.10410491.xyz/blog/kafka-vs-rabbitmq</link>
      <guid isPermaLink="true">https://www.10410491.xyz/blog/kafka-vs-rabbitmq</guid>
      <pubDate>Wed, 17 Jun 2026 12:00:00 GMT</pubDate>
      <category>System Design</category>
      <description>一個我們選錯的開場 先講一個我自己選錯的故事。 有個內部系統，需求很單純：幾個服務之間要做非同步解耦，把一些任務丟出去讓別的服務慢慢處理，量不大，一天頂多幾十萬則。當時團隊裡「Kafka = 高大上的訊息系統」的印象很深，選型會議十分鐘就拍板用 Kafka。 結果呢？我們為了這個不大的需求，扛上了 Kafka 一整套的運維重量——ZooKeeper（那個年代還要）、分區規劃、消費者位移管理。真正用…</description>
    </item>
    <item>
      <title>寫了金流與交易所系統之後，我怎麼管自己的錢</title>
      <link>https://www.10410491.xyz/blog/engineer-personal-finance</link>
      <guid isPermaLink="true">https://www.10410491.xyz/blog/engineer-personal-finance</guid>
      <pubDate>Wed, 17 Jun 2026 10:00:00 GMT</pubDate>
      <category>生活</category>
      <description>我第一次認真看自己的錢，是在某個凌晨三點對帳對到一半的時候。 那陣子我在做交易所的清算與對帳模組。我盯著螢幕上一排又一排的交易紀錄，某筆入金的金額跟銀行端回報差了幾塊錢手續費，整條對帳就卡住，紅字一路往下跳。我花了快兩個小時才找到，原來是某個第三方支付的回呼把手續費四捨五入到不同的小數位。事情解完，我靠在椅背上，腦袋突然冒出一個很荒謬的念頭：我能把一間交易所每天幾千萬的金流對到一分不差，那我自己的…</description>
    </item>
    <item>
      <title>遠端工作這幾年：我真實的作息、專注方法，與那些沒人會告訴你的代價</title>
      <link>https://www.10410491.xyz/blog/remote-work-three-years</link>
      <guid isPermaLink="true">https://www.10410491.xyz/blog/remote-work-three-years</guid>
      <pubDate>Tue, 16 Jun 2026 11:00:00 GMT</pubDate>
      <category>生活</category>
      <description>我第一次完全在家工作的那天，是個禮拜一的早上。我記得很清楚，因為那天我九點半才開電腦，泡了一杯咖啡，心裡想著「太爽了，再也不用通勤」，然後一路混到中午，午餐後躺在沙發上滑手機，回過神來已經三點，我那天幾乎什麼正事都沒做。晚上躺在床上的時候，我有一種很微妙的罪惡感——不是因為偷懶被抓到，而是因為沒人在看，我才發現原來支撐我規律工作的，從來不是自律，而是辦公室那套外在結構。 那是大概三年多前的事。後來…</description>
    </item>
    <item>
      <title>時間與時區的坑：我在金流與跨國系統踩過的雷</title>
      <link>https://www.10410491.xyz/blog/timezone-datetime-pitfalls</link>
      <guid isPermaLink="true">https://www.10410491.xyz/blog/timezone-datetime-pitfalls</guid>
      <pubDate>Tue, 16 Jun 2026 10:00:00 GMT</pubDate>
      <category>Backend Engineering</category>
      <description>做後端久了會發現，最容易被低估的就是「時間」。它看起來只是一個欄位、一個 timestamp，但時間牽涉到時區、日光節約、自然日的定義、排程、量測，每一個都能讓你在半夜被叫起來查帳。這篇講我在金流對帳、跨國活動、報表統計裡實際踩過的雷，以及我後來定下的幾條鐵則——因為時間錯一秒、錯一天、錯一個時區，在錢的世界裡都是要負責的。 第一條鐵則：儲存一律用 UTC，顯示才轉當地時區 這是我所有原則裡最不肯…</description>
    </item>
    <item>
      <title>深入游標分頁：當交易紀錄一邊翻頁一邊插入新資料時，OFFSET 為什麼會壞掉</title>
      <link>https://www.10410491.xyz/blog/cursor-pagination-deep-dive</link>
      <guid isPermaLink="true">https://www.10410491.xyz/blog/cursor-pagination-deep-dive</guid>
      <pubDate>Tue, 16 Jun 2026 10:00:00 GMT</pubDate>
      <category>System Design</category>
      <description>那天客服轉來的截圖 我先講那個讓我下定決心重寫分頁的早上。 那是某個交易所專案，使用者在 App 上翻自己的成交紀錄。她截了兩張圖給客服：第一頁最底下那筆成交，跟第二頁最上面那筆，是一模一樣的同一筆交易。同一個訂單號、同一個成交價、同一個時間戳，出現了兩次。她的問題很合理：「我到底是不是被重複扣款了？」 當然沒有重複扣款，重複的只是「顯示」。但對一個拿真金白銀在交易的人來說，看到自己的成交紀錄出現…</description>
    </item>
    <item>
      <title>把運動寫進每天的 commit：一個久坐工程師的身體保養實錄</title>
      <link>https://www.10410491.xyz/blog/desk-job-health-routine</link>
      <guid isPermaLink="true">https://www.10410491.xyz/blog/desk-job-health-routine</guid>
      <pubDate>Mon, 15 Jun 2026 11:00:00 GMT</pubDate>
      <category>生活</category>
      <description>先承認一件事：我曾經把健康放在 backlog 最底層 我做後端十幾年了，主力 Go，做過交易所的撮合引擎、金流串接、各種高併發的後台系統。這行的人都懂，當系統上線在即、當 production 半夜噴 alert、當一個 race condition 你怎麼追都追不到的時候，這個世界上只剩下你跟那台螢幕。吃飯可以晚一點，睡覺可以晚一點，水可以等一下再喝，廁所可以再忍一下。身體？身體是那個永遠排在…</description>
    </item>
    <item>
      <title>別在部署時掉訂單：我在 Go 服務裡實作優雅關閉的完整心法</title>
      <link>https://www.10410491.xyz/blog/graceful-shutdown-go</link>
      <guid isPermaLink="true">https://www.10410491.xyz/blog/graceful-shutdown-go</guid>
      <pubDate>Mon, 15 Jun 2026 10:00:00 GMT</pubDate>
      <category>Backend Engineering</category>
      <description>每次滾動更新，舊的 Pod 都要被換掉。問題是：那一刻你的服務正在做什麼？可能正處理一筆下單、正在跟金流對帳、正在把一則訊息寫進資料庫。如果這時候行程被一刀斬斷，輕則使用者看到一個莫名其妙的錯誤，重則一筆交易做到一半、錢扣了單沒成立。這篇講我怎麼在 Go 服務裡做優雅關閉，把「部署」這件每天都在發生的事，從一個風險變成一個無感的動作。 先講清楚：直接 kill 行程會出什麼事 很多人覺得部署就是「…</description>
    </item>
    <item>
      <title>那天記憶體在十秒內噴到 OOM：交易所即時行情的 WebSocket 推送是怎麼活下來的</title>
      <link>https://www.10410491.xyz/blog/websocket-realtime-market-data</link>
      <guid isPermaLink="true">https://www.10410491.xyz/blog/websocket-realtime-market-data</guid>
      <pubDate>Mon, 15 Jun 2026 10:00:00 GMT</pubDate>
      <category>Backend Engineering</category>
      <description>凌晨兩點的那通電話 那是一個很普通的週四凌晨，我記得很清楚，因為前一天我才剛把行情推送服務的版本更上線，本來想說可以睡個好覺。結果兩點十七分手機響了，值班的同事說行情服務的其中一台節點記憶體從穩定的 1.2 GB 在大概十秒內衝到 7 GB 然後被 OOM Killer 幹掉，然後負載飄到另一台，另一台也跟著倒。我打開監控，看到的是一條幾乎垂直的記憶體曲線，那種你只要看過一次就會做惡夢的曲線。 當…</description>
    </item>
    <item>
      <title>我的手沖咖啡日常：一杯咖啡如何幫我進入工作狀態</title>
      <link>https://www.10410491.xyz/blog/pour-over-coffee-daily</link>
      <guid isPermaLink="true">https://www.10410491.xyz/blog/pour-over-coffee-daily</guid>
      <pubDate>Sun, 14 Jun 2026 11:00:00 GMT</pubDate>
      <category>生活</category>
      <description>我不是那種會講「咖啡是生活的全部」的人。我是寫後端的，平常跟我相處最久的不是咖啡杯，是終端機跟一堆 Go 的 goroutine。但這幾年下來，我發現每天早上那杯自己手沖的咖啡，已經變成我啟動一天最重要的開關。不是因為它多好喝——雖然真的有變好喝——而是因為那段沖咖啡的時間，幫我把「還沒醒的人」切換成「準備好寫扣的工程師」。 這篇想老實聊聊這件事。不是要教你成為咖啡專家，我也不是。只是想分享一個工…</description>
    </item>
    <item>
      <title>一個第三方介面變慢，沒設逾時，把我整個下單服務拖垮了</title>
      <link>https://www.10410491.xyz/blog/timeout-retry-circuit-breaker</link>
      <guid isPermaLink="true">https://www.10410491.xyz/blog/timeout-retry-circuit-breaker</guid>
      <pubDate>Sun, 14 Jun 2026 10:00:00 GMT</pubDate>
      <category>System Design</category>
      <description>一根沒設逾時的呼叫，拖垮一整條線 那次故障的起點，小到你會覺得不可思議：一個第三方的金流查詢介面，變慢了。 不是掛掉，是變慢——本來幾十毫秒回應的東西，那天開始要等三十秒、六十秒才回。而我們呼叫它的那行程式碼，沒有設逾時。於是每一個打到這個介面的請求，都癡癡地等在那裡，佔著一個連線、一個 worker。幾分鐘之內，我的下單服務把整個連線池、整個 worker 都耗光了，連跟這個第三方完全無關的請求…</description>
    </item>
    <item>
      <title>凌晨三點的 OOM：我用 pprof 抓出 Go 服務裡四隻漏了三個月的 goroutine</title>
      <link>https://www.10410491.xyz/blog/go-goroutine-memory-leak-pprof</link>
      <guid isPermaLink="true">https://www.10410491.xyz/blog/go-goroutine-memory-leak-pprof</guid>
      <pubDate>Sun, 14 Jun 2026 10:00:00 GMT</pubDate>
      <category>Backend Engineering</category>
      <description>那張鋸齒狀的記憶體圖 那是一個負責推播行情的 Go 服務，把交易所撮合引擎吐出來的成交、掛單變動，透過 WebSocket 廣播給幾萬個前端連線。它跑得好好的，直到某天 PagerDuty 在凌晨三點十七分把我吵醒。 告警內容是 OOMKilled。Pod 的 memory limit 設 2GB，被 Kubernetes 砍掉重啟。我半睡半醒地打開 Grafana，看到那張我這輩子都忘不了的圖：…</description>
    </item>
    <item>
      <title>別等到燒壞才停下來：高壓工程工作裡，我怎麼保持續航</title>
      <link>https://www.10410491.xyz/blog/avoiding-burnout-engineer</link>
      <guid isPermaLink="true">https://www.10410491.xyz/blog/avoiding-burnout-engineer</guid>
      <pubDate>Sat, 13 Jun 2026 11:00:00 GMT</pubDate>
      <category>生活</category>
      <description>我不太喜歡「burnout」這個詞被講得太輕。這幾年它變成一種社群媒體上的流行語，誰都可以隨口說一句「我快 burnout 了」，然後配一張在咖啡廳的照片。但真正的倦怠不是那樣的。真正的倦怠是你坐在電腦前面，盯著一個你以前覺得很有趣的問題，然後發現自己什麼感覺都沒有。不是討厭它，也不是害怕它，就是——空的。 我想誠實地寫一篇關於這件事的文章。不是要給誰建議，也不是要喊什麼「工程師也要照顧自己」的口…</description>
    </item>
    <item>
      <title>可觀測性實戰：我在 Go 服務裡怎麼埋 log、metrics、trace</title>
      <link>https://www.10410491.xyz/blog/observability-logs-metrics-traces</link>
      <guid isPermaLink="true">https://www.10410491.xyz/blog/observability-logs-metrics-traces</guid>
      <pubDate>Sat, 13 Jun 2026 10:00:00 GMT</pubDate>
      <category>DevOps</category>
      <description>線上半夜出事的時候，你最不想看到的就是一片漆黑。服務回應變慢、錯誤率往上飆，但你打開系統一看，只有一行又一行毫無頭緒的 log，沒有任何線索告訴你「到底是哪一條請求、卡在哪個環節、為什麼慢」。我在交易所做撮合引擎、做金流串接的那幾年，最深刻的體會不是怎麼把功能寫出來，而是當事情出錯時，你有沒有辦法在三分鐘內知道發生了什麼事。這就是可觀測性（Observability）要解決的問題。這篇講我在 Go…</description>
    </item>
    <item>
      <title>PostgreSQL 還是 MySQL？兩個都被它咬過之後的老實話</title>
      <link>https://www.10410491.xyz/blog/postgres-mysql-production-tradeoffs</link>
      <guid isPermaLink="true">https://www.10410491.xyz/blog/postgres-mysql-production-tradeoffs</guid>
      <pubDate>Sat, 13 Jun 2026 10:00:00 GMT</pubDate>
      <category>Database</category>
      <description>凌晨三點，磁碟剩 4% 那是一個禮拜五的凌晨，我手機震到從床上彈起來。監控告訴我交易所後台的 PostgreSQL 主庫磁碟使用率衝到 96%，而且還在往上爬。那台機器掛了 2TB 的 SSD，三個禮拜前還只用了一半。 我登進去第一件事是看哪個 table 肥成這樣。結果是一張記錄使用者掛單狀態變更的表，叫它 orderevents 好了。實際資料量大概 80GB，但這張表在磁碟上佔了快 600G…</description>
    </item>
    <item>
      <title>工具越少，我反而做得越多：一個後端工程師的數位極簡實驗</title>
      <link>https://www.10410491.xyz/blog/digital-minimalism-productivity</link>
      <guid isPermaLink="true">https://www.10410491.xyz/blog/digital-minimalism-productivity</guid>
      <pubDate>Fri, 12 Jun 2026 11:00:00 GMT</pubDate>
      <category>生活</category>
      <description>我得先承認一件有點難堪的事：我曾經是那種會花一整個週末研究生產力工具的人。 不是用工具，是研究工具。我會打開 YouTube，看別人怎麼用某個筆記軟體建立「第二大腦」，看完熱血沸騰，立刻下載，花三個小時把它設定到我心目中完美的樣子。然後過了兩週，我又看到另一個影片，介紹另一套號稱更厲害的系統，於是我又把資料搬過去，再花三個小時設定。 我電腦裡那時候同時裝著三套待辦軟體、兩套筆記軟體、一個我自己用試…</description>
    </item>
    <item>
      <title>分散式交易與最終一致性：Saga 與補償交易的實務</title>
      <link>https://www.10410491.xyz/blog/distributed-transaction-saga</link>
      <guid isPermaLink="true">https://www.10410491.xyz/blog/distributed-transaction-saga</guid>
      <pubDate>Fri, 12 Jun 2026 10:00:00 GMT</pubDate>
      <category>System Design</category>
      <description>服務一旦拆開，最先碎掉的東西往往不是程式碼，而是「交易」這個概念。在單體時代，下訂單、扣庫存、扣款這三件事可以包在同一個資料庫交易裡，要嘛全成功、要嘛全回滾，乾淨俐落。但當訂單、庫存、金流變成三個獨立服務、各自有自己的資料庫，那個熟悉的 BEGIN 到 COMMIT 就再也圈不住它們了。這篇講我在交易所與金流系統裡，怎麼面對這個問題：為什麼最終一致性是被逼出來的選擇、Saga 兩種風格怎麼選、補償…</description>
    </item>
    <item>
      <title>部署不等於發布：我用 Feature Flag 把支付路由從 1% 灰度到 100% 的那一週</title>
      <link>https://www.10410491.xyz/blog/feature-flags-progressive-delivery</link>
      <guid isPermaLink="true">https://www.10410491.xyz/blog/feature-flags-progressive-delivery</guid>
      <pubDate>Fri, 12 Jun 2026 10:00:00 GMT</pubDate>
      <category>DevOps</category>
      <description>那天凌晨兩點，我沒有 rollback，只改了一個布林值 先講一個畫面。 去年我們要換掉一個用了三年的支付路由邏輯。舊的邏輯是：所有刷卡交易固定打第一家收單行，失敗才轉第二家。問題是第一家在每天晚上 11 點到凌晨 1 點的對帳批次期間，授權成功率會從平常的 96% 掉到 88% 左右。每天就那兩個小時，我們白白損失大概八個百分點的成交。以我們當時一天約四萬筆刷卡、平均客單一千二來算，那兩小時內的…</description>
    </item>
    <item>
      <title>資料庫索引實戰：我怎麼抓慢查詢、怎麼加對的索引</title>
      <link>https://www.10410491.xyz/blog/database-indexing-slow-query</link>
      <guid isPermaLink="true">https://www.10410491.xyz/blog/database-indexing-slow-query</guid>
      <pubDate>Thu, 11 Jun 2026 10:00:00 GMT</pubDate>
      <category>Database</category>
      <description>做後端這麼多年，慢查詢大概是我半夜被叫起來的前三名原因。流量一上來，原本毫秒級的查詢突然變成幾秒，連線池被塞滿，整個服務就跟著躺平。多數人第一反應是「加台機器」或「加快取」，但很多時候真正的病因只是少了一個索引，或加了一個沒被用到的索引。這篇講我實際在交易所訂單系統、金流串接上怎麼抓慢查詢、怎麼判斷該加什麼索引，以及那些「明明加了索引卻沒用」的真實的坑。背景以 PostgreSQL 和 MySQL…</description>
    </item>
    <item>
      <title>凌晨三點的那通電話：在 24 小時交易所值班，教會我的事</title>
      <link>https://www.10410491.xyz/blog/oncall-incident-response-lessons</link>
      <guid isPermaLink="true">https://www.10410491.xyz/blog/oncall-incident-response-lessons</guid>
      <pubDate>Thu, 11 Jun 2026 10:00:00 GMT</pubDate>
      <category>Career</category>
      <description>凌晨三點，手機在枕頭邊震動 那天是禮拜三，準確說是禮拜四的凌晨三點十一分。我記得這麼清楚，是因為後來寫 postmortem 的時候，那個時間戳被我貼進了 timeline 的第一行。 手機亮起來的瞬間，我整個人從淺眠裡彈起來。不是被吵醒的那種，是身體在睡著的狀態下，耳朵還掛著一根弦，PagerDuty 的鈴聲一響，腎上腺素先到，意識後到。我手在黑暗裡摸索，先碰到水杯差點打翻，才抓到那支發燙的手機…</description>
    </item>
    <item>
      <title>一批 key 同一秒過期，瞬間把 DB 打爆——我在高併發下的快取取捨</title>
      <link>https://www.10410491.xyz/blog/cache-consistency-penetration-avalanche</link>
      <guid isPermaLink="true">https://www.10410491.xyz/blog/cache-consistency-penetration-avalanche</guid>
      <pubDate>Wed, 10 Jun 2026 10:00:00 GMT</pubDate>
      <category>Backend Engineering</category>
      <description>同一秒過期的那批 key 那次 DB 被打爆，來得又快又猛。 監控上 DB 的 QPS 在幾秒內從平常的水位直接飆到頂，連線瞬間被打滿，一堆請求開始逾時。查下去，原因蠢得讓人有點不甘心：我們有一大批快取，是在同一個時間點被一起寫進去的（一次批次預熱），於是它們的過期時間也幾乎一模一樣。時間一到，這批 key 在同一秒集體失效，那一瞬間所有本來被快取擋住的流量，全部穿過去直接砸到 DB。 這就是所謂…</description>
    </item>
  </channel>
</rss>