一、非功能性需求（NFR, Non-Functional Requirements）

這是最常被忽略、但最容易出事的地方。

• 可用性（Availability）
  • SLA / SLO（例如 99.9% uptime）
• 延遲（Latency）
  • API 回應時間目標（例如 < 200ms）
• 吞吐量（Throughput）
  • 每秒請求數（QPS）
• 容量規劃（Capacity）
  • 預估用戶數 / 資料量成長

👉 沒寫這個，系統很容易「功能正確但撐不住流量」

二、資料治理（Data Governance）

當系統變大，這部分會變超重要。

• 資料保存期限（Retention policy）
• 軟刪除 vs 硬刪除（soft delete）
• GDPR / 個資法（如果有）
• 資料備份與還原策略（backup & restore）

三、設定與 Feature Flag

避免每次改東西都要 deploy。

• Feature flag（開關功能）
• 動態設定（config service）
• 灰度發布（gradual rollout）

四、併發與一致性（Concurrency & Consistency）

這是很多 junior spec 完全不會寫的點，但很關鍵：

• 競爭條件（race condition）怎麼處理
• 鎖（DB lock / distributed lock）
• 交易（transaction）範圍
• 最終一致性（eventual consistency）

👉 例如：

• 同一筆訂單被重複付款怎麼辦？
• 庫存超賣怎麼避免？

五、失敗處理與韌性（Resilience）

不是「會不會壞」，而是「壞了怎麼辦」。

• Retry 機制（exponential backoff）
• Circuit breaker
• Timeout 設定
• Dead letter queue（DLQ）

六、排程與背景任務（Async Jobs）

很多系統不只 API。

• 排程任務（cron jobs）
• Queue 設計（RabbitMQ / Kafka）
• 任務重試與去重（idempotency）

七、觀測性（Observability）

不只是 logging，而是能「看懂系統」。

• Metrics（Prometheus）
• Tracing（OpenTelemetry）
• Alert（告警條件）
• Dashboard（Grafana）

八、版本與相容性（Versioning & Compatibility）

避免你改 API 直接炸前端。

• API version（v1 / v2）
• 向後相容（backward compatibility）
• Deprecation policy（淘汰策略）

九、文件與開發者體驗（DX）

讓別人（或未來的你）好用。

• Swagger / OpenAPI
• 範例 request / response
• 錯誤碼對照表
• Mock server / sandbox

十、權限細節（比 RBAC 更細）

很多 spec 只寫「有權限」，但沒寫「怎麼判斷」。

• 資源層級權限（resource-level permission）
• 多租戶（multi-tenant）隔離
• 權限快取策略

十一、成本與資源（Cost Awareness）

這是資深工程師會開始考慮的。

• DB 成本（讀寫量）
• 第三方 API 成本
• 儲存成本（S3 / blob）
• Cache 命中率

十二、Migration / 上線策略（超常被忽略）

系統不是從 0 開始的話，一定要寫：

• 舊系統 → 新系統的資料遷移
• 雙寫（dual write）
• 回滾策略（rollback）
• 停機 or 無縫上線

一、領域建模（Domain Modeling）

這是從「寫 API」升級到「設計系統」。

• 核心實體（Entity）與聚合（Aggregate）
• 不變條件（invariants）
• Domain event（例如：OrderCreated）

👉 重點不是 table，而是「業務怎麼被抽象」

二、邊界與責任切分（Boundaries）

避免系統越寫越亂。

• Service boundary（哪個服務負責什麼）
• Anti-corruption layer（隔離外部系統）
• BFF（Backend for Frontend）是否需要

👉 沒寫這個，最後會變「誰都可以改這個 API」

三、API 使用規範（API Contract Discipline）

不只是定義 API，而是定義「怎麼用」。

• Rate limit policy（不同 client 不同限制）
• Pagination 標準（cursor vs offset）
• Filtering / sorting 規則
• Idempotency key 使用方式

四、資料演進策略（Schema Evolution）

資料不是一次定型的。

• 向前 / 向後相容（forward/backward compatibility）
• 欄位新增 / 移除策略
• nullable vs required 設計原則
• 舊資料補齊（backfill）

五、事件與資料流（Event Flow）

當系統開始用 queue / event-driven，這塊很關鍵。

• Event schema 定義
• 誰 publish / 誰 consume
• At-least-once vs exactly-once
• 重複事件處理（deduplication）

六、跨服務交易（Distributed Transactions）

只要有多服務，一定會遇到：

• Saga pattern（補償機制）
• 最終一致性流程圖
• 部分失敗時的補救策略

👉 這通常是「訂單成立但付款失敗」那種場景

七、災難復原（Disaster Recovery, DR）

不是「會不會掛」，而是「掛了多久能回來」。

• RTO（Recovery Time Objective）
• RPO（Recovery Point Objective）
• 多區部署（multi-region）
• failover 流程

八、資料隱私與稽核（Audit & Compliance）

如果系統有用戶資料，這很快就會變重要。

• Audit log（誰做了什麼）
• 敏感資料遮罩（masking）
• 存取紀錄（access log）
• 法規（例如金融、醫療）

九、開發流程與協作（Engineering Process）

這其實應該寫進 spec 或附錄。

• Code review 規範
• Branch strategy（Git flow / trunk-based）
• Definition of Done（DoD）
• 文件更新責任

十、依賴管理（Dependencies）

很多系統掛掉是因為依賴沒想清楚。

• 第三方 SLA
• 降級策略（degradation）
• Mock / fallback 機制

十一、系統限制（Known Limitations）

這點非常成熟，但很少人寫。

• 已知 bottleneck
• 不支援的 use case
• 技術債（technical debt）

👉 這能避免未來的人「誤用系統」

十二、On-call / 維運手冊（Runbook）

這是「能不能真的上 production」的分水嶺。

• 常見問題（FAQ）
• 故障排查步驟
• 指標異常怎麼看
• 手動操作流程（例如補資料）

一個很現實的結論

如果把後端 spec 分等級，大概是這樣：

• 🟢 初階：API + DB + 流程
• 🟡 中階：加上效能、安全、測試
• 🔵 進階：加上併發、事件、觀測性
• 🟣 資深：開始寫「會壞的地方」與「怎麼活下來」

你現在問「還有什麼」，其實已經在往 🟣 走了。