<?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>後端工程師 Louis Wu 的第一手技術與生活文章：Go、金流、高併發、系統設計。</description>
    <language>zh-Hant</language>
    <lastBuildDate>Thu, 18 Jun 2026 12:00:00 GMT</lastBuildDate>
    <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>不停機改 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>這幾年我待過交易所撮合、金流、後台這幾種系統，最讓我半夜不敢睡的，從來不是寫新功能，而是「線上改資料表」。新功能寫壞了，最多就是某個按鈕點下去沒反應，使用者罵兩句；但 schema 改錯，可能整張訂單表被鎖住，所有下單、出金、對帳全部卡住，那種壓力是完全不同等級的。 這篇我想把自己這幾年在正式環境改 schema 的流程整理出來。不是教科書那種「理論上應該這樣」，而是我實際踩過坑、被 oncall…</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 還是 RabbitMQ，我怎麼選</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 不是預設答案，RabbitMQ 也不是。它們解決的根本就不是同一類問題。 選型選錯，不會馬上爆。它會在半年後、在某個你以為…</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>把運動寫進每天的 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>我的手沖咖啡日常：一杯咖啡如何幫我進入工作狀態</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>服務一旦拆開，呼叫就從「函式呼叫」變成「網路呼叫」。函式呼叫要嘛回傳、要嘛 panic，幾乎是瞬間的事；網路呼叫多了第三種狀態——「卡住」。我看過太多次線上事故，根因都不是某個服務掛掉，而是某個服務「變慢」，然後慢的代價沿著呼叫鏈一路傳染，最後整個系統一起倒。這篇講的就是怎麼防這件事：逾時、重試、熔斷，還有它們背後的艙壁隔離與降級。這些都是我在交易所和金流系統上真的踩過、調過、半夜被叫起來救過的東…</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>工具越少，我反而做得越多：一個後端工程師的數位極簡實驗</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>資料庫索引實戰：我怎麼抓慢查詢、怎麼加對的索引</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>快取一致性與三大災難：穿透、擊穿、雪崩，我在高併發下的取捨</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>只要系統一上量，快取幾乎是必經之路。資料庫扛不住的讀流量，加一層 Redis 就解了大半。但我做過交易所行情、活動搶購、後台報表這些場景之後，慢慢體會到：加快取不難，難的是快取跟資料庫怎麼維持一致，以及在流量打進來的那一刻，快取會用什麼姿勢崩給你看。這篇講我對快取一致性的理解，還有穿透、擊穿、雪崩這三個經典災難——它們不是面試題，是真的會在半夜把你叫醒的東西。 先講清楚：快取一致性不是「強一致」 …</description>
    </item>
    <item>
      <title>雙寫一致性的惡夢：我如何用 Transactional Outbox 救回遺失的訂單訊息</title>
      <link>https://www.10410491.xyz/blog/transactional-outbox-pattern</link>
      <guid isPermaLink="true">https://www.10410491.xyz/blog/transactional-outbox-pattern</guid>
      <pubDate>Tue, 09 Jun 2026 10:00:00 GMT</pubDate>
      <category>System Design</category>
      <description>那天我盯著監控看板，發現一個很詭異的現象：資料庫裡明明有一筆已付款的訂單，但下游的出貨服務完全沒收到通知。客戶付了錢，貨卻沒出。這不是程式邏輯寫錯，而是一個更底層的問題——我同時要寫資料庫、又要發訊息到 MQ，這兩件事根本不是原子的。這篇講我怎麼從這個坑爬出來，用 Transactional Outbox Pattern 把雙寫一致性問題解掉，以及實務上那些沒人會在投影片上告訴你的細節。 問題的本…</description>
    </item>
    <item>
      <title>為什麼我在服務之間選 gRPC，以及它真實的坑</title>
      <link>https://www.10410491.xyz/blog/grpc-microservices-go</link>
      <guid isPermaLink="true">https://www.10410491.xyz/blog/grpc-microservices-go</guid>
      <pubDate>Thu, 04 Jun 2026 10:00:00 GMT</pubDate>
      <category>Backend Engineering</category>
      <description>當服務開始拆分，第一個要決定的就是：服務之間怎麼溝通。多數人預設用 REST/JSON，這沒錯，但在內部服務之間，我越來越常選 gRPC。這篇講我選它的理由，以及實際用下來真實的坑——因為它不是沒有代價的。 為什麼是 gRPC 在「服務對服務」這種機器跟機器的溝通場景，gRPC 有幾個對我很實際的好處： - 強型別的契約：用 protobuf 定義介面與訊息，產生各語言的程式碼。欄位型別、必填與否…</description>
    </item>
    <item>
      <title>Redis 在我的系統裡的幾種用法：快取、分散式鎖、排行榜</title>
      <link>https://www.10410491.xyz/blog/redis-patterns-cache-lock-ranking</link>
      <guid isPermaLink="true">https://www.10410491.xyz/blog/redis-patterns-cache-lock-ranking</guid>
      <pubDate>Mon, 01 Jun 2026 10:00:00 GMT</pubDate>
      <category>System Design</category>
      <description>很多人對 Redis 的印象停在「一個很快的快取」。它確實是，但在我做的高併發系統裡，Redis 扮演的角色遠不只如此。這篇講我實際用 Redis 的幾種方式、各自要注意什麼，以及那些「用錯會出大事」的細節。 一、快取：最常見，但魔鬼在失效 快取是 Redis 最基本的用途：把昂貴的查詢結果存起來，下次直接拿，省掉資料庫的負擔。簡單，但真正難的從來不是「存」，是「什麼時候讓它失效」。 我踩過的坑：…</description>
    </item>
    <item>
      <title>用 Go 打造交易所撮合引擎：訂單簿設計與我踩過的坑</title>
      <link>https://www.10410491.xyz/blog/go-matching-engine-orderbook</link>
      <guid isPermaLink="true">https://www.10410491.xyz/blog/go-matching-engine-orderbook</guid>
      <pubDate>Thu, 28 May 2026 10:00:00 GMT</pubDate>
      <category>Backend Engineering</category>
      <description>撮合引擎是交易所的心臟。它要做的事情聽起來很單純：把買單和賣單湊在一起成交。但當你真的動手寫，而且還要承受每秒上萬筆下單、絕對不能算錯一分錢的時候，魔鬼全在細節裡。這篇是我用 Go 實作撮合引擎時，真正踩過、也真正影響到正式環境的幾個重點。 為什麼撮合引擎要單執行緒 第一個反直覺的決定：撮合核心不要用多執行緒。 很多人第一反應是「這麼高的吞吐量，當然要平行處理」。但撮合的本質是一連串對共享狀態（訂…</description>
    </item>
    <item>
      <title>用訊息佇列解耦：我在金流與訂單系統的非同步設計</title>
      <link>https://www.10410491.xyz/blog/message-queue-async-decoupling</link>
      <guid isPermaLink="true">https://www.10410491.xyz/blog/message-queue-async-decoupling</guid>
      <pubDate>Mon, 25 May 2026 10:00:00 GMT</pubDate>
      <category>System Design</category>
      <description>「一筆訂單成立後，要寄通知、更新庫存、產發票、加積分……」如果這些全部同步做完才回應使用者，那使用者要等很久，而且任何一步掛掉，整筆就失敗。訊息佇列就是用來解決這種問題的。這篇講我在金流與訂單系統裡，實際怎麼用訊息佇列做非同步解耦，以及它帶來的新問題。 為什麼要非同步 同步處理的問題是強耦合：主流程要等所有附帶的事都做完，而且綁死了所有下游的可用性。訊息佇列把這件事翻轉過來：主流程只要把「訂單成立…</description>
    </item>
    <item>
      <title>設計一個會被別人用很久的 API：版本、錯誤碼與分頁</title>
      <link>https://www.10410491.xyz/blog/api-design-versioning-pagination</link>
      <guid isPermaLink="true">https://www.10410491.xyz/blog/api-design-versioning-pagination</guid>
      <pubDate>Thu, 21 May 2026 10:00:00 GMT</pubDate>
      <category>Backend Engineering</category>
      <description>寫一個能跑的 API 很快，但設計一個「會被別人用很多年、而且你還得持續維護」的 API，是完全不同的功夫。一旦有人開始依賴你的 API，你的每一個設計決定都變成要長期背負的承諾。這篇講我設計 API 時，最在意的幾件事：版本、錯誤、分頁，以及一致性。 一致性比聰明重要 我設計 API 的第一原則：一致性勝過個別的巧思。命名風格、日期格式、分頁方式、錯誤結構，整套 API 要長得一樣。 當使用者學…</description>
    </item>
    <item>
      <title>金流串接實戰：冪等、對帳與 Webhook 的那些坑</title>
      <link>https://www.10410491.xyz/blog/payment-gateway-idempotency-reconciliation</link>
      <guid isPermaLink="true">https://www.10410491.xyz/blog/payment-gateway-idempotency-reconciliation</guid>
      <pubDate>Mon, 18 May 2026 10:00:00 GMT</pubDate>
      <category>Backend Engineering</category>
      <description>金流是那種「平常沒事、出事就是錢」的系統。我整合過好幾家金流商，從信用卡到第三方支付，最深的體會是：金流串接真正的難度不在「打 API 送出付款」，而在處理各種「我不確定到底成功了沒」的中間狀態。這篇講幾個你一定會遇到的坑。 冪等是金流的第一原則 使用者在結帳頁狂點「付款」、手機網路斷線後重試、前端 timeout 但後端其實成功了——這些都會讓同一筆訂單的付款請求送出多次。如果你沒做冪等，使用者…</description>
    </item>
    <item>
      <title>限流實戰：令牌桶、漏桶，以及我在 API 上真正做的事</title>
      <link>https://www.10410491.xyz/blog/rate-limiting-token-bucket</link>
      <guid isPermaLink="true">https://www.10410491.xyz/blog/rate-limiting-token-bucket</guid>
      <pubDate>Thu, 14 May 2026 10:00:00 GMT</pubDate>
      <category>System Design</category>
      <description>任何對外的 API 都會遇到這個問題：有人（不管是惡意攻擊、寫壞的程式、還是爬蟲）瘋狂打你的服務。沒有限流，一個失控的來源就能把你的系統資源吃光，害到所有其他正常使用者。這篇講限流的幾個常見演算法，以及我在實務上真正怎麼做。 為什麼一定要限流 限流要保護的，不只是擋惡意攻擊，更是保護系統不被任何單一來源拖垮： - 擋掉惡意的暴力請求、刷接口 - 防止一個寫壞的客戶端（無限迴圈狂打）害到大家 - 保…</description>
    </item>
    <item>
      <title>活動網站搶購系統:用 Go 與 Redis 扛住瞬間高併發</title>
      <link>https://www.10410491.xyz/blog/flash-sale-high-concurrency-go-redis</link>
      <guid isPermaLink="true">https://www.10410491.xyz/blog/flash-sale-high-concurrency-go-redis</guid>
      <pubDate>Fri, 08 May 2026 10:00:00 GMT</pubDate>
      <category>System Design</category>
      <description>活動網站最刺激的時刻,就是整點開搶的那一秒。平常每秒幾十個請求的系統,在開搶瞬間可能衝到每秒上萬。而且搶購有個比一般流量更難的點:庫存是有限的,而且絕對不能超賣。送出 100 個名額,結果賣出 101 個,就是事故。這篇講我怎麼用 Go 加 Redis 扛住這種場景。 第一件事:別讓流量打到資料庫 最直覺的寫法是「查庫存 → 夠就扣 → 寫訂單」,全部打 DB。這在開搶瞬間會瞬間把資料庫連線池打爆…</description>
    </item>
  </channel>
</rss>