一旦使用者逐漸增加，線上應用流量開始因為業務而持續上升，多到系統無法承受時，就需要讓系統具備擴充能力，來要關注怎麼樣去做 scaling，或者說可伸縮性 Scalability ，其中又有「垂直擴充 vertical scaling」 和「水平擴充 horizontal scaling」 兩種擴充方向。
vertical scaling 是直接給機器換上像是更強的 CPU、更多的記憶體、更大的硬碟等等，但這個通常不是系統設計想考察的 ; 通常說的 scalability 都是指 horizontal scaling（簡稱 scaling），而此方式可以細分成以下三種方法 :
- 增加副本 : 將資料複製成多份 Scale Cube ，放在更多的地方
- 資料分區 : 會在每台機器上會保留一部分資料
- 功能分區 : 將一個系統按照功能，去拆分為更小的子系統
back-of-the-envelope calculations 中文翻譯是「粗略估算」，英文字面上的意思就是在一張信封後面就能隨手計算這樣，雖然簡單但卻一定要有一些事實根據來判斷和計算數字。真的開始在系統設計之前，會跟面試官或者是 PM 或者是自己調查，得到一些參數比如說 Daily active user 有多少等等的，再來會需要由這些假設的參數來「估算一下」系統性能會需要承擔多少，例如有以下常見的指標:
- QPS(Queries Per Second)
- Latency
- Storage Size
- Network bandwidth
這些不僅幫助我們了解系統設計的邊界，也讓我們掌握系統在不同併發情境下的 performance。值得注意的是「計算上其實都有一些小技巧」和「既有數值推估」可以去留意。
在做 System Design 時，可以有幾個階段來協助思考，分別是：
- 釐清探索需求 Requirement，而對於產品有所謂的 :
- Functional 功能需求 : 是從使用者的角度來看，可以用「User要能夠…」做為開頭句來思考產品本身要達到的功能
- Non-Functional 非功能需求 : 從系統的角度來看，可以用「系統要能夠…」做為開頭句來思考，可以把這類需求理解成「品質」要求，例如 : 可擴展性、可靠性、高 Performance 低 latency、可承受高 QPS 等等
- 架構 High-Level Architecture Design : 給初步的系統架構，依照資料流把會用到的相關元件題出，思考每一個部件優缺點，並概略把流程串起來
- Detail Deep dive : 更深入的說明要用的工具、算法、資料結構、框架，流程上資料怎麼進入、儲存、處理、輸出格式等等
雖然 System Design 範圍很大，但其實也是有不少模板和套路可以練習。可以多看看各式各樣系統的 high-level 設計，順便把其中自己不熟悉的知識補上。
Manacher’s Algorithm (Manacher 的唸法
/ˈmænəkər/)，用是來尋找字串中的最長回文子字串 (Longest Palindromic Substring)的最優解法，時間複雜度可優化到了 O(n)。 在了解此演算法之前，可以先熟悉「 Dynamic Programming - 2D matrix 」和「 中心擴散法 (Expand Around Center) 」這些 O(n＾2) 的解法，在解題途中有蠻多直得注意的技巧和知識點可以學習，由於算是是常考題，就花些時間了解一下吧。
uv 是 Astral 公司推出的一款基於 Rust 編寫的「 Python 套件管理工具 」，雖然 Python 的套件管理生態內已經存在多種工具如 pip 、 poetry 、 conda 等等，但 uv 還是有出色表現，由於使用 Rust 進行編寫，uv 工具的速度讓人驚艷 ；且從「 安裝管理 Python 版本 」、「 虛擬環境建置」、「 package 依賴 」以上 uv 全部都統整好了，其目標是取代多種現有工具，為 Python 專案的開發和管理帶來了新的選擇。 uv 也成為 Astral 公司繼 Ruff (Python 程式碼檢查器和格式化工具) 之後，另一個知名的專案了。
前段時間發現自己對 Python 的 Iterable、Iterator、Generator 之間的差別並沒有很熟，我們都知道這些的共同點是均可使用 for loop 來遍歷。
再進一步思考一下所謂的
for-loop是怎麼實現呢： 首先用最簡單的 list 來說明，因為有 index 標示位置，故可以指定位置拿出來，蠻符合 for-loop 的使用直覺 ; 但是 dict 也是可以用 for loop 走訪呀，而它並不存在順序 ; 甚至 open 的 file 都可以用 for loop 結構來讀取每個 row ，那為什麼這個也能用 for-loop 呢？這背後有兩個核心概念：
- Iterable(可迭代對象)
- Iterator(迭代器)
在軟體工程中，有蠻多工作都會需要排程的，而 Linux 排程可透過 crontab 與 at ，而這兩個有啥異同呢？ 我們可以發現工作排程的方式基本上分成：
- 例行性的 : 每隔一定的週期就會需要處理，那就可以使用
rontab這個指令設定的任務循環- 突發性的 : 會訂一個時間點執行，但做完以後就沒有了，那就可以使用
at指令處理僅執行一次就結束的任務Cron 是 Linux 系統下的一個定時任務管理服務，為了要精確表示「何時」執行， 就發明了一個抽象的 Cron 表達式，相信大家都有看過類似
0 12 * * *這種在定時任務中常出現的寫法，像 「 GCP Cloud Scheduler」、「 GitHub Actions」、「 SpringBoot 的 @Scheduled」，都以 Cron 表達式來定義任務觸發時間點。
影音串流已經融入現今生活中，OTT (Over-the-top media service) 此類利用網路來提供影音內容的服務平台也非常普遍了(如 Netflix 等等)。使用者只需有穩定的網路連線與播放裝置，即可在線上隨時收看影音 ; 而內容提供者不需擁有大規模的硬體設備就能將影音內容放置於網路上。自己對於這技術大部份的專有名詞都還有蠻多不了解的。例如說「 MP4 」、「 1080P 」、「 H.264 」 等等，這些名詞基本上都看過，但實際上對於其定義是蠻模糊的，而更進階的 Streaming Protocol (串流協議)，在讀相關資料有也些蠻多名詞冒出來的，以下就把我認為對影片處理需要知道的事情，其資料簡單整理一下。
之前有介紹了 Message Queue 和其常見協定 MQTT 、 AMQP ，而 RabbitMQ 就是一款基於 AMQP 訊息傳遞協定實現的輕量級開源服務，由 Erlang 語言開發，能夠跨進程的傳遞訊息，且對多數主流程式語言如 Python、Java 等都有官方或社群開發 lib。
再來為了方便運維與監控，RabbitMQ 有內建一套 Web 介面，使用者可透過此介面管理檢視 queue 健康狀態，還可以處理使用者權限等操作
為了要把系統架構解耦，改為異步分散式處理，有時會決定使用 Message Queue 的設計來達成目標，其指的是應用程序之間通過在 Message Service 而不是直接調用彼此通訊。對於其落地的產品，常見的開源工具有 Kafka、RabbitMQ 等等或者雲端服務 GCP-Pub/Sub 和 AWS-SQS 等等。作為兩個子系統之間的通信中間層，會需要依靠協定保持有序且有效率的方式實現資訊交換，而目前廣泛使用的協定有 MQTT 和 AMQP ，以下也會簡單介紹一下。
