综合练习

把本 track 串起来：为 CodeRoadMap 的 tracks API 设计一套可扩展架构，并列出瓶颈与演进路径。目标不是画完美架构图，而是证明你能在 building-for-scale 节点上 说清取舍。

学习目标

• 综合运用无状态、缓存、读写分离、限流、队列等手段
• 产出瓶颈清单与分阶段演进计划（MVP → 10x → 100x）
• 交叉引用本 track 与 redis-essentials、nginx-essentials、kafka-essentials

任务说明

假设 tracks API 现状：单体 Spring Boot + PostgreSQL，峰值 500 QPS，P99 800ms。需求：支撑活动推广后 5000 QPS，读多写少，track 列表与详情占 90% 流量。

交付物

1. 架构图（ASCII 或 Mermaid）：Client → 边缘 → App → 缓存 → DB → 队列
2. 瓶颈清单：至少 5 项，每项标注组件、症状、优先级
3. 演进三阶段：每阶段改什么、预期 QPS、风险

Phase 1: 无状态 + Redis 缓存 + 读写分离
Phase 2: Nginx 限流 + Kafka 异步写统计
Phase 3: 分片（按 track_id）+ 多区域读副本

自检清单

• Session 是否外置？见 scale-stateless
• 列表接口是否存在 N+1？见 scale-n1
• 缓存 miss 与 DB 故障是否有降级？见 reliability-essentials
• 超流量时 429 还是排队？见 scale-backpressure
• CAP 取舍是否写进设计说明？见 scale-cap

加分项

• 用 spring-cloud-essentials 组件替换图中自定义部分并说明理由
• 估算 Redis 内存：10 万 track 详情，平均 2KB，命中率 95% 时 DB 剩余 QPS

练习

• 完成上述三份交付物（可写在 PR 或笔记里）
• 与同伴交叉 review：对方架构最先崩的是哪一环
• 回到 全栈路线图，勾选 building-for-scale 相关节点