針對高負載、高資料交換、高流動性的 Web 2.0 型大型網站（如社群平台、即時互動社區），語言選擇非關鍵，架構設計才是核心。以下整理 10 個不得不正視的架構層面議題。
單表百萬級資料下，傳統 SELECT/UPDATE 與索引策略失效。需引入分表、分庫、冷熱資料分離、NoSQL 輔助查詢等手段，將單表查詢成本控制在可接受範圍。
全域共享快取在高併發寫入時易發生競態條件導致服務雪崩。需設計：快取更新鎖機制、延雙刪策略、最終一致性補償、資料庫死鎖監控與磁碟 I/O 隔離。
單機 500GB 碎檔案會拖垮檔案系統 I/O。方案：分布式檔案系統（HDFS、Ceph）、Object Storage（S3 相容）、按日期/業務/雜湊分桶儲存、CDN 邊緣緩存、上傳寫入流控。
Web 2.0 多對多關係普遍，第三範式須妥協。採用反正規化、冗余字段、物化視圖、CQRS 讀寫分離，將多表 JOIN 壓縮為單表或快取查詢。
高頻 UPDATE 環境下，聚簇索引維護成本極高（單次更新達 10 分鐘）。策略：減少非必要索引、使用附加索引、延遲索引重建、寫入分流至紀錄表再異步同步。
CDN 對動態內容無效。需解決：多地資料庫同步延遲、衝突解決、分散式事務（TCC/Saga）、一致性哈希路由、資料分片與遷移工具。
前端易構造高頻請求攻擊後端。防禦：API 速率限制、簽名驗證、非關鍵操作佇列化、前端防抖節流、關鍵運算後端冪等設計。
HTTP 明文傳輸易被分析、模擬、群發。對策：關鍵 API HTTPS、參數加密簽名、裝置指紋識別、行為風控、蜜罐偵測、核心邏輯 Server-side Rendering 降低前端暴露。
主從同步延遲秒級甚至分鐘級。架構需支援：讀寫分離路由、關鍵業務強制走主庫、資料雜湊分片、延遲感知的快取失效策略、異步最終一致性補償機制。
OpenAPI 成趨勢。需建立：API 閘道、權限模型（OAuth2/JWT）、配額限流、資料脫敏、審計日誌、版本生命週期管理、開發者門戶。
這 10 大議題相互關聯，無標準答案，唯有根據業務增長階段、團隊能力、成本預算持續演進架構。
