<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Multi-Tenant on YennJ12 Engineering Blog</title><link>https://yennj12.js.org/yennj12_blog_V4/tags/multi-tenant/</link><description>Recent content in Multi-Tenant on YennJ12 Engineering Blog</description><generator>Hugo -- gohugo.io</generator><language>en-us</language><lastBuildDate>Thu, 04 Jun 2026 16:00:00 +0800</lastBuildDate><atom:link href="https://yennj12.js.org/yennj12_blog_V4/tags/multi-tenant/feed.xml" rel="self" type="application/rss+xml"/><item><title>FDE 面試準備指南（二十三）：RKK 實戰——多租戶 Agent 的限流、Fair-Share 與 Token 預算控制</title><link>https://yennj12.js.org/yennj12_blog_V4/posts/fde-interview-guide-part23-ratelimit-fairshare-zh/</link><pubDate>Thu, 04 Jun 2026 16:00:00 +0800</pubDate><guid>https://yennj12.js.org/yennj12_blog_V4/posts/fde-interview-guide-part23-ratelimit-fairshare-zh/</guid><description>傳統 SaaS 的限流是「每分鐘最多 1,000 個請求」。
AI SaaS 的限流問題是「每分鐘最多 100 萬個 Token，但一個用戶的一個請求就可能用掉 50 萬 Token」。
請求次數限流，在 AI 系統裡完全失效。
面試情境 面試官： 「你的 B2B SaaS 將 Agent 系統開放給上千家企業使用。Gemini API 有嚴格的 TPM/RPM 限制。如果某個大客戶突然發起高頻查詢，把整個 GCP 專案的 Quota 耗盡，導致其他客戶全部收到 429 Too Many Requests。你如何在架構端設計 Fair-Share 與 Token 預算控制系統？」
一、核心問題：為什麼 AI 限流和傳統 API 限流完全不同 傳統 API 的資源消耗模型： 每個請求的成本大致相同 GET /users/123 ≈ GET /orders/456 ≈ 相同的計算資源 → 限制「請求次數（RPM/RPS）」就夠了 AI API 的資源消耗模型： 請求 A：「你好！」 → input: 50 tokens, output: 30 tokens = 80 tokens 請求 B：「請分析這份 200 頁的合約並翻譯成英文」 → input: 150,000 tokens, output: 50,000 tokens = 200,000 tokens 請求 B 消耗的資源是請求 A 的 2,500 倍！ 如果只限制請求次數（RPM）： → 請求 B 讓整個系統的 Token Quota 瞬間耗盡 → 其他 99 個正常用戶全部 429 問題量化（Gemini 1.</description></item><item><title>Building a Centralized User Access Control System with AWS Cognito and CDK</title><link>https://yennj12.js.org/yennj12_blog_V4/posts/centralized-user-access-control-aws-cognito-cdk/</link><pubDate>Sun, 30 Nov 2025 13:00:00 +0000</pubDate><guid>https://yennj12.js.org/yennj12_blog_V4/posts/centralized-user-access-control-aws-cognito-cdk/</guid><description>🎯 Introduction Building a centralized user access control system is one of the most critical architectural decisions for modern applications. Whether you&amp;rsquo;re managing a single application or a microservices ecosystem, having a robust, scalable authentication and authorization system is essential for:
Single Source of Truth: One system managing all user identities and permissions Consistency: Uniform authentication experience across all services Security: Centralized security policies and compliance controls Scalability: Support for millions of users across multiple applications Developer Experience: Simple integration for new services Cost Efficiency: Managed service without operational overhead This comprehensive guide demonstrates how to design and implement a production-ready centralized access control system using AWS Cognito and CDK (TypeScript), with strategies for multi-tenancy, role-based access control (RBAC), and integration patterns for various services.</description></item></channel></rss>