https://yennj12.js.org/yennj12_blog_V4/tags/scalability/Recent content in Scalability on YennJ12 Engineering BlogHugo -- gohugo.ioen-usMon, 08 Jun 2026 10:00:00 +0800https://yennj12.js.org/yennj12_blog_V4/posts/kubernetes-autoscaling-complete-guide-part1-horizontal-pod-autoscaler/Sun, 09 Nov 2025 10:00:00 +0800https://yennj12.js.org/yennj12_blog_V4/posts/kubernetes-autoscaling-complete-guide-part1-horizontal-pod-autoscaler/Part 1 of the Kubernetes Autoscaling series: Deep dive into Horizontal Pod Autoscaler (HPA) approaches, comparing resource-based, custom metrics, external metrics, and event-driven autoscaling with KEDA. Learn when to use each approach with real-world examples and production best practices.https://yennj12.js.org/yennj12_blog_V4/posts/fde-core-concept-12-backpressure-fair-share-zh/Mon, 08 Jun 2026 10:00:00 +0800https://yennj12.js.org/yennj12_blog_V4/posts/fde-core-concept-12-backpressure-fair-share-zh/核心定義：Backpressure 是下游受限資源（GPU 配額、LLM 速率上限）主動向上游發出「放慢」訊號的機制；Fair-Share 排程確保在削峰過程中每個租戶仍獲得保證的最低吞吐量，讓流量尖峰不會讓任何單一租戶將其他人餓死。 一、為什麼面試官問這個 多租戶 AI 平台的核心挑戰不是「如何服務單一大客戶」，而是「如何讓 500 個中小租戶與 5 個企業租戶共存，同時保證 SLA」。面試官用這個題目測試三件事： 系統思維：你是否理解流量從 API Gateway → Queue → Worker → LLM 整條鏈的壓力傳導方式，而不只是會設定 nginx rate limit。拿到這類題目，強答案一定會在 2 分鐘內畫出流量路徑，標明每個節點的限速機制。 數字直覺：Redis Token Bucket 0.5 ms vs DB-based 15 ms；在 50K req/s 的規模下，這個差距決定了你的 rate-limit 層是否成為系統瓶頸。能說出這個數字，代表你有實際操作過，不是只讀過文件。 公平性設計：高付費租戶應優先，但「優先」不等於「獨占」。能說清楚 floor rate 與 burst allowance 的區別，以及它們如何透過獨立 worker pool 實現隔離，才算真正懂多租戶設計。 弱答案長這樣：「我會用 nginx 的 limit_req 或 API Gateway 的 quota 設定來限速，超限就回 429。」— 這只說到最表層；沒提 Token Bucket 內部機制、Redis 的原子性問題、Pub/Sub 作為無限緩衝的作用，也沒有 Fair-Share 的 weighted queuing 概念。https://yennj12.js.org/yennj12_blog_V4/posts/fde-interview-guide-part39-scalability-zh/Mon, 08 Jun 2026 09:00:00 +0800https://yennj12.js.org/yennj12_blog_V4/posts/fde-interview-guide-part39-scalability-zh/10,000 個內部員工用，一切都很順。 百萬外部用戶第一天上線，系統在 30 分鐘內崩潰。 「加更多機器」不是答案—— 正確的問題是：哪些地方讓你根本無法加機器？ 面試情境 面試官：「你幫一家金融公司做了內部員工 AI 助手，10,000 個內部用戶，系統很穩定。現在 CEO 決定把這個產品開放給外部客戶，目標是百萬 MAU（月活躍用戶）。你說需要重新設計架構。從哪裡開始？你會做哪些改動？為什麼？」 一、為什麼 10K → 1M 不只是「加機器」 10K 內部用戶的隱性假設（這些假設在 1M 時全部失效）： 用戶行為： ├── 行為模式可預測（9-18 點工作時間，流量曲線平滑） ├── 用量相對均勻（員工配額相似，不會有人瘋狂濫用） └── 系統問題可以容忍（內部用戶有耐心，可以接受偶爾慢） 系統設計： ├── Session State 在記憶體（少數實例，重啟少） ├── 認證：單一 LDAP/SSO（一種身份系統就夠） ├── 沒有速率限制（員工不會惡意攻擊自家系統） └── SLA：P95 < 10s 內部用戶接受 1M 外部用戶：每一個假設都被打破 假設失效 真實挑戰 系統症狀 ────────────────────────────────────────────────────────────── 行為可預測 病毒式傳播：1 小時內 100x 流量 Auto-Scale 來不及 → 503 用量均勻 惡意用戶濫用、失控的客戶端 Bug 一個用戶拖垮整個平台 Session 在記憶體 Scale-Out 後新實例找不到 Session 對話斷掉，用戶流失 無速率限制 機器人、爬蟲、Bug 迴圈呼叫 LLM 配額耗盡 → 全平台崩潰 SLA 寬鬆 外部客戶不等待，直接離開 用戶留存率崩潰 成本不計較 1M × 50 queries × $0.https://yennj12.js.org/yennj12_blog_V4/posts/mysql-sharding-strategies-comprehensive-guide/Mon, 29 Sep 2025 07:54:22 +0800https://yennj12.js.org/yennj12_blog_V4/posts/mysql-sharding-strategies-comprehensive-guide/🎯 Introduction Database sharding is a critical technique for achieving horizontal scalability in large-scale applications. As data volumes grow beyond what a single database instance can handle efficiently, sharding becomes essential for maintaining performance and availability. This comprehensive guide explores MySQL sharding strategies, comparing different approaches, implementation patterns, and real-world considerations. Sharding involves distributing data across multiple database instances (shards), where each shard contains a subset of the total data. This approach enables applications to scale beyond the limitations of vertical scaling and provides better resource utilization across multiple servers.https://yennj12.js.org/yennj12_blog_V4/posts/microservices-architecture-patterns/Sun, 10 Aug 2025 15:28:17 +0800https://yennj12.js.org/yennj12_blog_V4/posts/microservices-architecture-patterns/Deep dive into proven microservices architecture patterns that help organizations scale their systems effectively while maintaining reliability and developer productivity.