Kubernetes 有個很方便的地方：只要修改 deployment 的 spec.replicas 數字，就能橫向擴展 pod，以應付更大的流量負載需求。

這一招，對於 stateless 的 HTTP 服務很管用，也是 Kubernetes 入門教學愛用的例子。但是，對於 gRPC 呢？

最近幾年，在微服務打滾的人，不時會遇到神祕的 “idempotency key” 字眼。本文爬梳 idempotency key 的技術背景，探討運作流程，並分析資料庫的實作選項。

Idempotency 冪等性

在 API 服務中，常常需要留意 idempotency（冪等性）。

名詞：idempotency，形容詞：idempotent。

“Idempotency” 這字眼源自數學。維基百科是這麼解釋 “idempotent function” 的：

在網路上看到 Joe 喟然嘆曰：「今天重要功課：仔細看過明天 20 位履歷課同學的履歷以及繳交的功課。說起來這堂課好像是我們最耗能的一堂課，完全是做功德的一堂課。」

我，身為履歷表價值鏈另一端的面試官，也很能瞭解這番滋味。¹

近年來，履歷教戰守則廣傳，有專書，甚至還有專門課程。理論上，「不懂得 包裝美化履歷 正確呈現履歷」的低級錯誤應該會越來越少見——其實不然。驚訝的是，即使是獵頭轉來的履歷也常無法倖免，真不知該怎麼說了。

遇到比較多的反例，是沒有亮點。

年初，告別服務五年的單位，走出舒適圈，歸零，重啟。

如果說 2018 是收攝靜觀的一年，那麼，2019 可謂驚滔駭浪了。做對了一些事，也犯下許多蠢事。

到了年終，又開始要做個總回顧，再對來年許願。去除一些不便揭露的事情，以下是簡單的回顧。

年底，人才流動的旺季。

這陣子，經手一堆履歷，更面試超過十場，深深覺得，若多一點人懂得面試的遊戲規則，甚至更廣義的職場遊戲規則，將是賓主盡歡的美事。

Bryan 說得好：「求職過程投入越多，越能理解這個遊戲規則，也對自己的目標更清晰！」

我們或許都沒有前衛到像 Netflix《給力》那樣「鼓勵員工經常去面試別家公司的工作」，但說實話，多一些面試與被面試的經歷，的確能夠更掌握遊戲規則，也會衝擊到自己原先的浪漫幻想，降低美麗的錯誤，將自己導向更務實的定位。

面試與被面試都經歷過不少的我，想針對這陣子的所見所聞，分享一些個人的觀點。