為什麼要設計 SaaS 架構？

在四年的接案經驗中，我的專案都是獨立開發，導致：

• 技術棧分散：Python FastAPI、Kotlin Spring Boot、Go Gin、React和Vue
• 部署困難：每個專案的部署方式都不同，前期是指令後期是Makefile指令
• 無法複用：相似功能重複開發，無法形成產品線
• 維護困境：客戶需求變更時，每個系統都要單獨修改

加上去年開了工作室，也該是時候打造屬於工作室的SaaS產品，從而擺脫各種客製化的服務，可以推出一套SaaS產品來尋找機會。
因此決定建立統一的 Kyo-System SaaS 平台，從 OTP 驗證微服務開始，逐步替換既有系統。

Kyo-System 整體產品架構

系統藍圖：

┌─────────────────────────────────────────────────────────────────────┐
│                        EXTERNAL SYSTEMS                            │
├─────────────────┬─────────────────┬─────────────────┬──────────────┤
│  Legacy Frontend│  Legacy Backend │  Mitake SMS     │  Monitoring  │
│  • Vue/React    │  • FastAPI/SB   │  • OTP Sending  │  • Sentry/AMP│
└─────────────────┴─────────────────┴─────────────────┴──────────────┘
                                    │ REST
                                    ▼
┌─────────────────────────────────────────────────────────────────────┐
│                           FRONTEND (MANAGEMENT)                     │
│                    React Vite + Mantine + Zustand + ORPC           │
│                    • OTP Form • Template Mgmt • Logs               │
└─────────────────────────────────────────────────────────────────────┘
                                    │ ORPC
                                    ▼
┌─────────────────────────────────────────────────────────────────────┐
│                         API GATEWAY                                │
│                TypeScript + Fastify                               │
│              • ORPC (Internal) • REST (External)                  │
└─────────────────────────────────────────────────────────────────────┘
                                    │
                    ┌───────────────┼───────────────┐
                    ▼               ▼               ▼
        ┌─────────────────┐ ┌─────────────────┐ ┌─────────────────┐
        │   AUTH SERVICE  │ │  GYM SERVICE    │ │  BOOKING SERVICE│
        │  TS + Fastify   │ │ (Future)        │ │ (Future)        │
        │  + Redis/Prisma │ │                 │ │                 │
        └─────────────────┘ └─────────────────┘ └─────────────────┘
                                    │
                                    ▼
┌─────────────────────────────────────────────────────────────────────┐
│                       DATA & MESSAGE LAYER                         │
├─────────────────┬─────────────────┬─────────────────┬──────────────┤
│  RDS PostgreSQL │  ElastiCache   │  Redis Streams  │  S3 Storage  │
│  • OTP Logs     │  • OTP Cache   │  • OTP Events   │  • Files     │
└─────────────────┴─────────────────┴─────────────────┴──────────────┘

AWS 服務選型策略

為什麼要選擇AWS服務呢？主要是熟悉AWS的服務，在之前的工作有深度的使用AWS的服務打造前後端的部署流程，加上使用過AWS和GCP，還是AWS比較符合我的需求。

為什麼選擇這些 AWS 服務？

計算層 - ECS Fargate

• ✅ 無伺服器容器：不需要管理 EC2 實例
• ✅ 自動擴展：根據負載自動調整容器數量
• ✅ 成本效益：只為運行的容器付費
• ✅ 整合性：與 ALB、CloudWatch 無縫整合

資料庫層 - RDS PostgreSQL

• ✅ Multi-AZ 高可用：自動故障轉移
• ✅ 自動備份：可以自動備份和恢復
• ✅ 版本管理：自動處理安全更新
• ✅ 效能監控：Performance Insights

快取層 - ElastiCache Redis

• ✅ 記憶體快取：OTP 暫存與速率限制
• ✅ Redis Streams：事件驅動架構
• ✅ 叢集模式：水平擴展支援
• ✅ 自動備份：災難恢復

前端託管 - S3 + CloudFront

• ✅ 全球 CDN：快速內容分發
• ✅ HTTPS 支援：SSL 憑證自動管理
• ✅ 成本最低：靜態託管最佳選擇

後面開始設計第一階段目標，OTP 驗證微服務的部署環境。