系统设计案例库（40个系统）

涵盖 Web/Mobile/Desktop 三端，覆盖社交、电商、金融、出行、游戏、企业SaaS等多个行业。 用「思考框架」的5层分析拆解每个系统。

目录

基础设施类

1. URL Shortener（短链接）⭐⭐ [Web]
2. Rate Limiter（限流器）⭐⭐⭐ [基础设施]
3. Distributed ID Generator（分布式ID生成器）⭐⭐ [基础设施]
4. Notification System（通知系统）⭐⭐⭐ [Web+Mobile]
5. Task Scheduler（任务调度器）⭐⭐⭐ [基础设施]

社交与内容类

6. News Feed（信息流）⭐⭐⭐⭐ [Web+Mobile]
7. Chat System（聊天系统）⭐⭐⭐⭐ [Web+Mobile+Desktop]
8. YouTube（视频平台）⭐⭐⭐⭐⭐ [Web+Mobile]
9. Instagram/小红书（图片社交）⭐⭐⭐⭐ [Mobile优先]
10. Twitter/X（短内容平台）⭐⭐⭐⭐ [Web+Mobile]
11. Spotify（音乐流媒体）⭐⭐⭐⭐ [Web+Mobile+Desktop]
12. TikTok（短视频推荐）⭐⭐⭐⭐⭐ [Mobile优先]

搜索与数据类

13. Search Engine（搜索引擎）⭐⭐⭐⭐ [Web]
14. Web Crawler（网页爬虫）⭐⭐⭐ [后端服务]
15. Analytics Platform（数据分析平台）⭐⭐⭐⭐ [Web]
16. Content Moderation（内容审核）⭐⭐⭐ [后端服务]

电商与交易类

17. Hotel Reservation（酒店预订）⭐⭐⭐⭐ [Web+Mobile]
18. E-commerce（电商平台）⭐⭐⭐⭐⭐ [Web+Mobile]
19. Payment System（支付系统）⭐⭐⭐⭐ [Web+Mobile]
20. Flash Sale（秒杀系统）⭐⭐⭐⭐ [Web+Mobile]

出行与位置类

21. Proximity Service（附近搜索）⭐⭐⭐ [Mobile]
22. Google Maps（地图导航）⭐⭐⭐⭐⭐ [Web+Mobile]
23. Uber/滴滴（打车平台）⭐⭐⭐⭐⭐ [Mobile]
24. Food Delivery（外卖平台）⭐⭐⭐⭐⭐ [Mobile]

存储与协作类

25. Google Drive（云存储）⭐⭐⭐⭐ [Web+Desktop+Mobile]
26. Google Docs（协同编辑）⭐⭐⭐⭐⭐ [Web+Desktop]
27. Dropbox（文件同步）⭐⭐⭐⭐ [Desktop+Web+Mobile]

游戏与实时类

28. Gaming Leaderboard（排行榜）⭐⭐⭐ [Web+Mobile]
29. Online Multiplayer Game（多人在线游戏）⭐⭐⭐⭐⭐ [Desktop+Mobile]
30. Live Streaming（直播系统）⭐⭐⭐⭐ [Web+Mobile]

企业与SaaS类

31. Email System（邮件系统）⭐⭐⭐⭐ [Web+Desktop+Mobile]
32. Calendar System（日历系统）⭐⭐⭐ [Web+Desktop+Mobile]
33. CRM（客户关系管理）⭐⭐⭐ [Web]
34. Monitoring & Alerting（监控告警）⭐⭐⭐⭐ [Web]

金融类

35. Stock Trading（股票交易）⭐⭐⭐⭐⭐ [Web+Desktop+Mobile]
36. Digital Wallet（数字钱包）⭐⭐⭐⭐ [Mobile优先]

移动端与桌面端专项

37. Push Notification Service（推送服务）⭐⭐⭐ [Mobile]
38. Offline-First App（离线优先应用）⭐⭐⭐ [Mobile]
39. IDE/Code Editor（代码编辑器）⭐⭐⭐⭐⭐ [Desktop]
40. Desktop Sync Client（桌面同步客户端）⭐⭐⭐ [Desktop]

---

1. Design a URL Shortener

第1层：用户层

• 谁在用？ 普通用户、营销人员、开发者
• 完成什么任务？ 把长链接变短，方便分享；点击短链接能跳转到原地址
• 成功标准？ 输入长URL → 秒级获得短链接 → 短链接可靠跳转 → 可查看点击统计

第2层：用户故事

1. 营销人员打开页面 → 粘贴长链接 → 点击生成 → 复制短链接 → 发到社交媒体
2. 用户点击短链接 → 浏览器自动跳转到原网页
3. 营销人员回来查看 → 看到该短链接被点了多少次、来自哪些地区

第3层：功能层

• MVP：输入长URL → 生成短码 → 短码跳转（301/302重定向）
• 后续：自定义短码、过期时间、点击统计面板、API接口

第4层：数据层

• 名词：短链接（short_code, original_url, created_at, expires_at, user_id）、点击记录（click_id, short_code, timestamp, ip, user_agent）
• 关系：一个短链接 → 多条点击记录；一个用户 → 多个短链接
• 必须保存：短码与原URL的映射、点击记录
• 展示用：统计图表（实时聚合）

第5层：流程层

• 生成短链接
  • Given：用户已打开页面
  • When：粘贴URL并点击生成
  • Then：系统生成唯一短码，存入数据库，返回短链接
  • And：如果URL已存在，返回已有短码（去重）
  • 失败路径：URL格式非法 → 提示错误
• 短链接跳转
  • Given：短码存在且未过期
  • When：用户访问短链接
  • Then：302重定向到原URL
  • And：记录一条点击日志
  • 失败路径：短码不存在/已过期 → 404页面

---

2. Design a Rate Limiter

第1层：用户层

• 谁在用？ API开发者、运维工程师、平台安全团队
• 完成什么任务？ 限制客户端请求频率，保护后端服务不被过载或滥用
• 成功标准？ 正常请求不受影响 → 超限请求被快速拒绝（返回429） → 规则灵活可配 → 分布式环境下计数准确

第2层：用户故事

1. 运维人员在配置面板设置规则：某API每用户每秒最多10次请求 → 保存生效
2. 正常用户发送请求 → 通过限流检查 → 正常返回数据
3. 恶意脚本高频请求 → 超过阈值后收到429 Too Many Requests → 返回头包含Retry-After
4. 运维查看监控 → 看到被限流的请求数、触发限流的Top客户端

第3层：功能层

• MVP：固定窗口计数器（按IP或API Key限流）、超限返回429、基本规则配置
• 后续：滑动窗口算法、令牌桶/漏桶算法、分布式限流（Redis集中计数）、多维度限流（按用户/IP/接口组合）、白名单、动态调整阈值

第4层：数据层

• 名词：限流规则（rule_id, resource, dimension[ip/user/api_key], limit, window_seconds）、计数器（key, count, window_start, ttl）、限流日志（timestamp, client_id, resource, action[pass/reject]）
• 关系：一个资源可配多条规则；一个客户端在每个窗口有一个计数器
• 必须保存：限流规则（持久化）、计数器（Redis，带TTL自动过期）
• 展示用：限流统计仪表盘、Top被限流客户端

第5层：流程层

• 请求限流检查
  • Given：限流规则已配置，计数器服务（Redis）可用
  • When：一个API请求到达网关/中间件
  • Then：根据请求维度（IP/用户/API Key）构造key → 查询当前窗口计数 → 若未超限则计数+1并放行 → 若超限则返回429
  • And：响应头附带X-RateLimit-Limit、X-RateLimit-Remaining、Retry-After
  • 失败路径：Redis不可用 → 降级策略（放行并告警 / 本地内存限流）
• 规则管理
  • Given：运维人员有管理权限
  • When：创建/修改限流规则
  • Then：规则持久化到数据库 → 同步到所有网关节点（配置中心/广播）
  • 失败路径：规则配置冲突 → 提示冲突并要求确认

---

3. Design a Distributed ID Generator

第1层：用户层

• 谁在用？ 后端开发者、微服务架构中的各业务系统
• 完成什么任务？ 在分布式环境中生成全局唯一、大致有序的ID，作为数据库主键或业务流水号
• 成功标准？ 生成速度快（微秒级） → 全局唯一不冲突 → ID有序（可按时间排序） → 高可用

第2层：用户故事

1. 订单服务创建新订单 → 调用ID生成器 → 获得唯一订单ID → 写入数据库
2. 多个服务节点同时请求ID → 不会生成重复ID
3. 运维查看ID → 能从中解析出大致生成时间和来源机器
4. 某台机器宕机 → 其他机器继续正常生成ID，无影响

第3层：功能层

• MVP：Snowflake算法（时间戳 + 机器ID + 序列号），单机每秒可生成数百万ID
• 后续：UUID v7（时间有序UUID）、号段模式（从数据库批量取号段缓存到本地）、Redis INCR方案、机器ID自动注册/回收、时钟回拨处理

第4层：数据层

• 名词：机器注册表（machine_id, hostname, registered_at, last_heartbeat）、号段表（biz_tag, max_id, step, updated_at）、生成的ID（64位整数：1bit符号 + 41bit时间戳 + 10bit机器ID + 12bit序列号）
• 关系：每台机器对应一个machine_id；号段模式下每个业务标签有独立计数
• 必须保存：机器注册表（确保machine_id不冲突）、号段表
• 展示用：ID生成QPS监控、各节点状态

第5层：流程层

• Snowflake生成ID
  • Given：服务节点已启动，已获取唯一machine_id
  • When：业务系统请求生成ID
  • Then：获取当前时间戳（毫秒） → 与上次时间比较 → 同一毫秒内序列号+1 → 不同毫秒则序列号重置 → 拼接（时间戳|machine_id|序列号）→ 返回64位ID
  • And：同一毫秒序列号溢出（>4095）→ 等待下一毫秒
  • 失败路径：检测到时钟回拨 → 拒绝生成并告警（或等待时钟追上）
• 机器ID注册
  • Given：新服务节点启动
  • When：向注册中心（ZooKeeper/数据库）申请machine_id
  • Then：分配一个未使用的machine_id → 记录映射 → 定期心跳续约
  • 失败路径：所有machine_id已用完 → 回收长时间无心跳的ID 或 告警扩容

---

4. Design a Notification System

第1层：用户层

• 谁在用？ 应用终端用户（接收通知）、业务系统（触发通知）、运营人员（配置模板和规则）
• 完成什么任务？ 将系统事件通过多种渠道（邮件、短信、推送、站内信）及时通知用户
• 成功标准？ 通知及时送达 → 渠道可配置 → 用户可管理偏好 → 不会骚扰用户（频率控制）

第2层：用户故事

1. 用户下单成功 → 收到站内信 + 邮件确认
2. 用户设置偏好：只接收邮件，关闭短信 → 之后不再收到短信通知
3. 运营编辑通知模板（包含变量占位符） → 保存 → 业务触发时自动填充内容
4. 系统检测到某用户1小时内已收到5条通知 → 后续通知进入静默/合并

第3层：功能层

• MVP：站内信通知 + 邮件通知、通知模板、已读/未读状态
• 后续：推送（FCM/APNs）、短信、用户偏好管理、频率控制（防骚扰）、通知分组与合并、定时发送、多语言模板

第4层：数据层

• 名词：通知（notification_id, user_id, channel, title, content, status[pending/sent/read], created_at）、模板（template_id, name, channel, subject_template, body_template, variables[]）、用户偏好（user_id, channel, enabled, quiet_hours）、发送记录（notification_id, channel, status, sent_at, error）
• 关系：一个事件可触发多条通知（多渠道）；一个模板用于多条通知；一个用户有多个渠道偏好
• 必须保存：通知记录、发送状态、用户偏好
• 展示用：未读数角标、通知列表

第5层：流程层

• 发送通知
  • Given：业务事件发生（如订单创建），通知模板已配置
  • When：业务系统调用通知API（传入用户ID、模板ID、变量）
  • Then：查用户偏好 → 确定发送渠道 → 检查频率限制 → 渲染模板 → 入消息队列 → 按渠道消费：邮件(SMTP)、推送(FCM/APNs)、短信(SMS网关)、站内信(写DB)
  • And：记录每条发送状态；失败自动重试（最多3次）
  • 失败路径：渠道不可用（如邮件服务宕机）→ 降级到其他渠道 → 告警运维
• 用户管理偏好
  • Given：用户已登录
  • When：在设置页修改通知偏好
  • Then：更新偏好表 → 后续通知按新偏好执行
  • 失败路径：至少保留一个渠道开启（防止完全收不到关键通知）

---

5. Design a Task Scheduler

第1层：用户层

• 谁在用？ 后端开发者（定义定时任务）、运维人员（监控任务执行）
• 完成什么任务？ 在指定时间或按Cron表达式定期执行任务（如数据清理、报表生成、消息推送）
• 成功标准？ 任务准时触发 → 不重复执行 → 失败可重试 → 支持百万级任务调度

第2层：用户故事

1. 开发者创建定时任务：每天凌晨2点清理过期数据 → 配置Cron表达式 → 任务按时执行
2. 运维查看调度面板 → 看到所有任务的下次执行时间、最近执行结果
3. 某任务执行失败 → 系统自动重试3次 → 仍失败则告警
4. 多台调度节点运行 → 同一任务只被一台节点执行（不重复）

第3层：功能层

• MVP：单机Cron调度 + 任务持久化（数据库存储） + 执行记录
• 后续：分布式调度（分布式锁确保不重复执行）、DAG依赖（任务A完成后触发任务B）、重试策略（指数退避）、任务优先级、超时控制、监控告警面板

第4层：数据层

• 名词：任务（task_id, name, cron_expression, handler, params, status[enabled/disabled], next_fire_time, max_retries）、执行记录（execution_id, task_id, status[running/success/failed], started_at, finished_at, error_message, retry_count）、调度节点（node_id, hostname, last_heartbeat）
• 关系：一个任务有多条执行记录；多个节点竞争执行同一任务
• 必须保存：任务定义、执行记录
• 展示用：执行历史、成功率图表、下次触发时间

第5层：流程层

• 任务调度与执行
  • Given：任务已创建且状态为enabled，调度器轮询运行中
  • When：轮询发现有任务的next_fire_time <= 当前时间
  • Then：尝试获取分布式锁（防止多节点重复执行）→ 获取成功 → 标记任务为running → 执行handler → 记录结果 → 计算并更新next_fire_time → 释放锁
  • And：执行超时 → 强制终止并标记failed
  • 失败路径：执行失败 → 检查retry_count < max_retries → 是则安排重试（指数退避） → 否则标记最终失败并告警
• 任务依赖（DAG）
  • Given：任务B依赖任务A
  • When：任务A执行完成且状态为success
  • Then：检查任务B的所有前置依赖是否满足 → 满足则将任务B加入就绪队列
  • 失败路径：前置任务失败 → 跳过下游任务 → 通知相关人员

---

6. Design a News Feed System

第1层：用户层

• 谁在用？ 社交平台用户（发布者 + 浏览者）
• 完成什么任务？ 发布动态内容；打开首页看到关注的人最新动态
• 成功标准？ 发布后关注者能快速看到；首页加载快且内容按相关性/时间排序

第2层：用户故事

1. 用户A发布一条动态（文字+图片）→ 确认发布成功
2. 用户B（关注了A）打开首页 → 看到A的新动态出现在信息流中
3. 用户B下拉刷新 → 获取更多历史动态
4. 用户B点赞/评论 → 动态下方显示互动

第3层：功能层

• MVP：关注/取关、发布动态、拉取信息流（按时间倒序）
• 后续：推荐算法排序、无限滚动分页、推/拉模型混合（大V用拉，普通用户用推）、缓存

第4层：数据层

• 名词：用户（user_id, name）、动态/帖子（post_id, user_id, content, media_urls, created_at）、关注关系（follower_id, followee_id）、信息流（feed_id, user_id, post_id, score）
• 关系：用户 → 发布多条动态；用户 → 关注多个用户；信息流 = 用户关注的人的动态集合
• 必须保存：动态内容、关注关系
• 展示用：聚合后的信息流

第5层：流程层

• 发布动态
  • Given：用户已登录
  • When：提交动态内容
  • Then：存储动态 → 触发信息流分发（推模式：写入每个粉丝的feed缓存）
  • And：通知被@的用户
  • 失败路径：内容违规 → 审核拦截
• 拉取信息流
  • Given：用户已登录，有关注的人
  • When：打开首页或下拉刷新
  • Then：从feed缓存（或实时聚合）获取最新动态列表，按时间/分数排序返回
  • 失败路径：无关注 → 展示推荐内容/空状态

---

7. Design a Chat System

第1层：用户层

• 谁在用？ 普通用户（1对1聊天）、群组成员
• 完成什么任务？ 实时发送和接收文字/图片消息
• 成功标准？ 消息秒级送达，支持离线消息，历史消息可回溯

第2层：用户故事

1. 用户A打开和B的聊天窗口 → 输入消息 → 发送 → B实时收到
2. 用户B不在线 → A发消息 → B上线后收到未读消息并显示红点
3. 用户创建群组 → 邀请成员 → 群内发消息所有成员可见
4. 用户向上滑动 → 加载历史消息

第3层：功能层

• MVP：1对1聊天、WebSocket实时推送、消息持久化、离线消息推送
• 后续：群聊、已读回执、图片/文件发送、消息搜索、在线状态

第4层：数据层

• 名词：用户、会话（conversation_id, type[1v1/group], participants）、消息（message_id, conversation_id, sender_id, content, type, created_at, status）
• 关系：一个会话 → 多条消息；一个会话 → 多个参与者
• 必须保存：消息内容、会话关系
• 展示用：未读计数、在线状态

第5层：流程层

• 发送消息
  • Given：A和B有一个会话，A已连接WebSocket
  • When：A发送消息
  • Then：服务端存储消息 → 通过WebSocket推送给B（如B在线）→ 返回A发送成功
  • And：更新会话最后消息时间；如B离线 → 存入离线队列，B上线时批量推送
  • 失败路径：WebSocket断开 → 客户端自动重连并拉取缺失消息

---

8. Design YouTube

第1层：用户层

• 谁在用？ 视频创作者（上传者）、观众（浏览者）
• 完成什么任务？ 上传视频并被观看；浏览和观看视频
• 成功标准？ 上传流畅 → 自动转码 → 全球观众流畅播放 → 推荐相关视频

第2层：用户故事

1. 创作者上传视频文件 → 填写标题、描述、标签 → 提交 → 看到”处理中” → 完成后视频上线
2. 观众打开首页 → 看到推荐视频列表 → 点击播放 → 流畅观看
3. 观众搜索关键词 → 看到相关视频 → 点击观看
4. 观众点赞/评论/订阅创作者

第3层：功能层

• MVP：视频上传、转码处理、视频播放（自适应码率）、视频列表/搜索
• 后续：推荐系统、评论/点赞、订阅、播放历史、频道页面、直播

第4层：数据层

• 名词：用户、视频（video_id, uploader_id, title, description, tags, status[processing/live], created_at）、视频文件（video_id, resolution, format, storage_url）、评论、订阅关系、观看记录
• 关系：用户上传多个视频；视频有多个分辨率版本；用户订阅用户；视频有多条评论
• 必须保存：视频元数据、视频文件、用户数据
• 展示用：播放量、推荐列表

第5层：流程层

• 上传视频
  • Given：创作者已登录
  • When：上传视频文件并填写信息
  • Then：文件存入对象存储 → 触发转码任务（多分辨率） → 完成后更新状态为”已上线”
  • And：生成缩略图、提取时长等元信息
  • 失败路径：文件格式不支持 → 提示错误；转码失败 → 通知创作者
• 播放视频
  • Given：视频状态为”已上线”
  • When：观众点击播放
  • Then：根据网络状况选择合适码率 → 从CDN加载分片 → 边下边播
  • And：记录观看行为（用于推荐）；播放量+1

---

9. Design Instagram/小红书

第1层：用户层

• 谁在用？ 内容创作者（分享生活/好物）、浏览者（发现灵感/种草）、品牌商家（推广商品）
• 完成什么任务？ 发布精美图文/短视频内容；浏览发现感兴趣的内容；互动（点赞、评论、收藏）
• 成功标准？ 发布体验流畅（滤镜/编辑好用）→ 内容能被目标受众发现 → 互动活跃 → 首页推荐精准

第2层：用户故事

1. 创作者选择多张照片 → 应用滤镜/编辑 → 添加描述和标签 → 选择位置 → 发布 → 看到发布成功
2. 用户打开Explore/发现页 → 看到个性化推荐的图文内容 → 点击查看详情
3. 用户点赞 → 收藏 → 评论”在哪里买的？” → 创作者回复
4. 用户搜索”#露营装备” → 看到相关帖子列表
5. 创作者查看数据 → 看到曝光量、点赞数、收藏数、粉丝增长

第3层：功能层

• MVP：图片发布（多图 + 滤镜/基础编辑）+ 首页Feed + 点赞/评论 + 关注 + 个人主页
• 后续：短视频支持、Explore/发现推荐、Stories/笔记、标签系统、位置标记、电商（商品链接/店铺）、私信、直播、数据分析面板

第4层：数据层

• 名词：帖子（post_id, user_id, images[], caption, location, tags[], type[image/video], created_at）、评论（comment_id, post_id, user_id, content, parent_comment_id）、点赞（user_id, post_id）、收藏（user_id, post_id）、关注关系（follower_id, followee_id）、标签（tag_id, name, post_count）
• 关系：用户发布多个帖子；帖子包含多张图片；帖子有多个标签；评论可嵌套（回复）；用户关注用户
• 必须保存：帖子内容和图片、关注关系、互动数据
• 展示用：推荐Feed、Explore页、用户数据面板

第5层：流程层

• 发布帖子
  • Given：创作者已登录
  • When：选择图片 → 编辑（滤镜/裁剪）→ 填写描述和标签 → 发布
  • Then：图片压缩 + 生成多尺寸缩略图 → 上传到对象存储（S3/OSS）→ 写入帖子元数据 → 异步写入关注者Feed → 更新标签索引 → 更新推荐候选池
  • And：触发关注者通知（如开启）
  • 失败路径：图片处理失败 → 提示重试；内容违规 → 审核拦截不发布
• 浏览推荐（Explore）
  • Given：用户打开发现页
  • When：请求推荐内容
  • Then：推荐系统根据用户兴趣标签、历史行为、内容热度 → 召回候选帖子 → 排序 → 返回分页结果
  • And：记录曝光和点击行为用于反馈
  • 失败路径：冷启动用户（无行为数据）→ 展示热门/编辑推荐内容

---

10. Design Twitter/X

第1层：用户层

• 谁在用？ 内容发布者（个人/媒体/名人）、阅读者、广告主
• 完成什么任务？ 发布短内容（文字/图片/视频）；浏览实时信息流；参与话题讨论
• 成功标准？ 发推即时可见 → 时间线实时更新 → 话题趋势实时反映热点 → 搜索即时命中

第2层：用户故事

1. 用户撰写一条推文（280字+图片）→ 发送 → 粉丝时间线实时出现
2. 用户打开首页 → 看到关注的人的最新推文 + 算法推荐内容
3. 用户搜索”#WorldCup” → 看到实时相关推文流
4. 用户查看”趋势”→ 看到当前热门话题排行
5. 用户引用转发一条推文并加上评论 → 原作者收到通知

第3层：功能层

• MVP：发推（文字+图片）+ 关注 + 时间线（按时间倒序）+ 点赞/转发
• 后续：话题（Hashtag）、搜索、趋势（Trending）、引用转发、回复线程、书签、列表、推荐算法、广告系统、Spaces（语音聊天室）

第4层：数据层

• 名词：推文（tweet_id, user_id, content, media_urls[], reply_to_tweet_id, quote_tweet_id, created_at）、关注（follower_id, followee_id）、点赞（user_id, tweet_id）、转发（user_id, tweet_id）、话题（hashtag, tweet_count, trending_score）、趋势（topic, region, score, timestamp）
• 关系：用户发多条推文；推文可回复/引用另一条推文（树状线程）；用户关注用户；话题关联多条推文
• 必须保存：推文内容、关注关系、互动数据
• 展示用：时间线（聚合）、趋势排行

第5层：流程层

• 发推
  • Given：用户已登录
  • When：提交推文内容
  • Then：存储推文 → 异步扇出（Fan-out）到粉丝时间线缓存（大V用拉模式，普通用户用推模式）→ 提取Hashtag更新话题计数 → 更新搜索索引 → 更新趋势评分
  • And：如有@提及 → 通知被提及用户
  • 失败路径：内容违规 → 审核标记/限制可见
• 趋势计算
  • Given：推文流持续产生
  • When：流处理管道实时聚合
  • Then：按话题/关键词统计时间窗口内的推文数和加速度 → 计算趋势分数 → 按地区排序 → 更新趋势榜
  • And：过滤垃圾/刷量话题
  • 失败路径：流处理延迟 → 趋势数据可容忍分钟级延迟

---

11. Design Spotify

第1层：用户层

• 谁在用？ 听众（搜索/播放音乐）、艺术家/厂牌（上传发行音乐）、播客创作者
• 完成什么任务？ 听众发现和收听音乐/播客；创作者发行作品并获得收益
• 成功标准？ 搜索即出结果 → 播放无卡顿 → 推荐精准好听 → 支持离线下载 → 跨设备无缝切换

第2层：用户故事

1. 用户搜索”周杰伦” → 看到歌手页面、热门歌曲、专辑列表 → 点击播放
2. 用户播放歌曲 → CDN流式加载音频 → 无缝播放 → 播完自动播下一首
3. 用户创建歌单 → 添加歌曲 → 分享给朋友
4. 用户开启”每日推荐” → 看到个性化歌单 → 发现新歌
5. 用户在手机下载歌单 → 飞行模式下离线播放
6. 用户在手机播放 → 切到电脑客户端 → 继续从当前位置播放（跨设备切换）

第3层：功能层

• MVP：音乐上传（后台）+ 搜索 + 播放（流式）+ 基础歌单
• 后续：推荐系统（协同过滤+音频特征分析）、歌单管理与分享、离线下载（加密+DRM）、播客支持、跨设备切换（Spotify Connect）、社交（关注好友/查看好友在听什么）、歌词、艺术家数据面板

第4层：数据层

• 名词：歌曲（track_id, title, artist_ids[], album_id, duration, audio_files[{quality, storage_url}], genre）、专辑（album_id, title, artist_id, release_date, cover_url）、歌单（playlist_id, user_id, name, track_ids[], is_public）、播放记录（user_id, track_id, played_at, duration_played）、用户（user_id, subscription_type[free/premium]）
• 关系：歌曲属于专辑；歌手有多张专辑多首歌；歌单包含多首歌；用户有多个歌单和播放历史
• 必须保存：音频文件（对象存储+CDN）、歌曲元数据、播放记录（用于推荐和版税计算）
• 展示用：推荐歌单、排行榜、播放界面

第5层：流程层

• 播放歌曲
  • Given：用户选择了一首歌，有网络连接
  • When：点击播放
  • Then：客户端请求音频流URL → 根据用户订阅类型和网络质量选择码率 → CDN返回音频分片 → 边下边播（HTTP Range请求或HLS）
  • And：记录播放行为（用于推荐和版税分成）；更新最近播放列表
  • 失败路径：CDN节点不可用 → 自动切换备用节点；网络中断 → 播放本地已缓冲部分
• 离线下载
  • Given：用户是Premium会员
  • When：点击下载歌单
  • Then：后台逐首下载音频文件 → DRM加密存储到本地 → 标记为已下载
  • And：离线播放时本地解密播放；定期联网验证订阅有效性
  • 失败路径：存储空间不足 → 提示清理；订阅过期 → 离线歌曲不可播放
• 跨设备切换
  • Given：用户在设备A播放音乐
  • When：在设备B打开App并选择”接管播放”
  • Then：服务端记录当前播放状态（曲目+进度）→ 设备B获取状态 → 从断点继续播放 → 设备A停止
  • 失败路径：设备A离线 → 从服务端最后同步的状态恢复

---

12. Design TikTok

第1层：用户层

• 谁在用？ 短视频创作者、观众（所有年龄段）、广告主/品牌
• 完成什么任务？ 创作者录制编辑短视频并发布；观众刷推荐视频消费内容；品牌做广告投放
• 成功标准？ 录制编辑体验简单有趣 → 推荐精准（让人停不下来）→ 优质内容能快速破圈 → 视频加载无卡顿

第2层：用户故事

1. 创作者打开相机 → 录制15秒视频 → 添加音乐/特效/字幕 → 发布
2. 观众打开App → 全屏推荐视频自动播放 → 上滑下一个 → 沉浸式浏览
3. 观众看到喜欢的视频 → 双击点赞 → 评论 → 分享给朋友
4. 新创作者发布第一个视频 → 系统分配初始流量池 → 根据反馈数据决定是否扩大推荐
5. 观众搜索”做饭教程” → 看到相关视频列表

第3层：功能层

• MVP：视频录制/上传 + 推荐Feed（全屏上下滑动）+ 点赞/评论/分享
• 后续：特效/滤镜/音乐库、直播、电商（商品橱窗/直播带货）、Duet/合拍、创作者工具（数据分析）、广告系统、搜索

第4层：数据层

• 名词：视频（video_id, user_id, audio_id, description, tags[], duration, status[processing/live/removed]）、用户行为（user_id, video_id, watch_duration, completion_rate, liked, commented, shared, timestamp）、音频（audio_id, title, artist, file_url, use_count）、创作者数据（user_id, follower_count, total_likes, total_views）
• 关系：视频使用一个音频；用户对视频产生行为记录；视频有多个标签
• 必须保存：视频文件、用户行为数据（推荐核心）、审核结果
• 展示用：推荐Feed、创作者数据面板

第5层：流程层

• 视频发布
  • Given：创作者已录制/选择视频
  • When：添加编辑后点击发布
  • Then：客户端上传视频 → 服务端转码（多码率适配）→ 内容审核（AI初审）→ 审核通过后进入推荐池 → 分配初始流量池（如500次曝光）
  • And：生成封面缩略图；提取标签用于推荐
  • 失败路径：审核不通过 → 通知创作者并说明原因；转码失败 → 重试
• 推荐分发
  • Given：视频在推荐池中，有初始流量配额
  • When：系统向用户推荐该视频
  • Then：收集用户反馈（完播率、点赞率、评论率、分享率）→ 高于阈值 → 扩大流量池（如5000→50000→推荐全量）→ 低于阈值 → 减少推荐
  • And：推荐算法核心权重：完播率 > 点赞率 > 评论率 > 分享率（非关注关系驱动）
  • 失败路径：数据稀疏（新用户）→ 基于内容特征冷启动推荐
• 视频播放
  • Given：观众在推荐Feed
  • When：上滑切换到新视频
  • Then：预加载下2-3个视频 → CDN分发视频流 → 自动播放 → 记录观看时长
  • 失败路径：弱网 → 降低码率；加载超时 → 跳过并加载下一个

---

13. Design an Internal Search Engine

第1层：用户层

• 谁在用？ 公司内部员工
• 完成什么任务？ 在公司文档、知识库、代码仓库等内部资源中快速搜索信息
• 成功标准？ 输入关键词 → 秒级返回相关结果 → 结果按相关性排序 → 覆盖多种数据源

第2层：用户故事

1. 员工在搜索框输入关键词 → 回车 → 看到来自文档/Wiki/Slack的匹配结果
2. 员工点击某条结果 → 跳转到对应的原始文档页面
3. 员工使用筛选器（按来源、时间、作者）缩小范围

第3层：功能层

• MVP：全文搜索、结果排序、来源标识、分页
• 后续：筛选/过滤、搜索建议/自动补全、权限控制（只能搜到有权限的文档）、高亮匹配片段

第4层：数据层

• 名词：文档（doc_id, source, title, content, author, updated_at, permissions）、搜索索引（倒排索引）、搜索日志（query, user_id, timestamp, clicked_results）
• 关系：多种数据源 → 统一索引；用户 → 多条搜索记录
• 必须保存：索引数据、文档元信息
• 展示用：高亮片段、搜索建议

第5层：流程层

• 索引构建
  • Given：连接器配置好各数据源（Confluence、GitHub、Slack…）
  • When：定时任务触发 / 数据源有变更
  • Then：拉取新增/修改文档 → 清洗 → 分词 → 更新倒排索引
• 搜索查询
  • Given：索引已建立
  • When：用户输入关键词
  • Then：查倒排索引 → 计算相关性分数 → 过滤权限 → 返回排序结果
  • 失败路径：无匹配结果 → 展示”未找到”并建议修改关键词

---

14. Design a Web Crawler

第1层：用户层

• 谁在用？ 搜索引擎团队、数据分析师、SEO工具运营者
• 完成什么任务？ 自动从互联网抓取网页内容，建立索引/数据集
• 成功标准？ 给定种子URL → 自动发现并抓取相关页面 → 内容被正确存储 → 不重复抓取

第2层：用户故事

1. 运营人员输入种子URL列表 → 启动爬虫任务 → 系统开始抓取
2. 系统抓到一个页面 → 解析出新链接 → 加入待抓队列 → 继续抓取
3. 运营人员查看仪表盘 → 看到已抓取页面数、失败数、队列剩余数

第3层：功能层

• MVP：输入种子URL → BFS/DFS遍历抓取 → 去重 → 存储页面内容
• 后续：robots.txt遵守、频率控制（礼貌爬取）、分布式多节点、优先级调度、增量更新

第4层：数据层

• 名词：URL（url, domain, status, last_crawled_at）、页面内容（url, html, title, text, crawled_at）、爬虫任务（task_id, seed_urls, status）
• 关系：一个任务 → 多个URL；一个URL → 一份页面内容
• 必须保存：URL去重集合、页面内容
• 展示用：抓取进度、统计

第5层：流程层

• 抓取流程
  • Given：队列中有待抓URL
  • When：取出一个URL
  • Then：检查robots.txt → 发HTTP请求 → 解析HTML → 存储内容 → 提取新URL → 去重后入队
  • And：更新该URL状态为”已抓取”，记录抓取时间
  • 失败路径：请求超时/403 → 标记失败，稍后重试（最多N次）

---

15. Design an Analytics Platform

第1层：用户层

• 谁在用？ 产品经理（看用户行为）、数据分析师（深度分析）、运营人员（看活动效果）、开发者（集成SDK）
• 完成什么任务？ 采集用户行为数据，提供PV/UV/留存等报表，支持漏斗分析和自定义查询
• 成功标准？ SDK接入简单 → 数据采集不丢失 → 报表加载快 → 支持实时和历史数据查询

第2层：用户故事

1. 开发者在App中集成SDK → 配置事件埋点（如button_click, page_view）→ 上线后数据开始上报
2. PM打开分析面板 → 看到昨日DAU、新用户数、留存率曲线
3. 分析师创建漏斗：注册 → 首次下单 → 复购 → 看到每步转化率和流失人数
4. 运营查看A/B测试结果 → 对比实验组和对照组的转化率 → 决定是否全量上线
5. 分析师使用SQL查询自定义报表 → 导出CSV

第3层：功能层

• MVP：事件采集SDK（Web+Mobile）+ 基础报表（PV/UV/DAU/留存）+ 事件列表
• 后续：漏斗分析、用户路径分析、A/B测试、实时看板、自定义SQL查询、用户分群、归因分析、数据导出

第4层：数据层

• 名词：事件（event_id, event_name, user_id, device_id, properties{}, timestamp, device_info{os, version, screen}）、用户属性（user_id, first_seen, last_seen, custom_attributes{}）、漏斗定义（funnel_id, steps[], time_window）、报表（report_id, type, query, cached_result）
• 关系：一个用户产生多条事件；漏斗由多个事件步骤组成；报表基于事件数据聚合
• 必须保存：原始事件数据（写入后不可变）、用户属性
• 展示用：聚合报表、图表、漏斗可视化

第5层：流程层

• 数据采集
  • Given：SDK已集成，埋点已配置
  • When：用户在App中触发事件（如点击按钮）
  • Then：SDK收集事件+设备信息 → 批量上报（每30秒或满50条）→ 采集服务接收 → 写入消息队列（Kafka）
  • And：实时流处理（Flink/Spark Streaming）→ 写入列式存储（ClickHouse）用于查询；同时写入对象存储（S3）用于归档
  • 失败路径：网络不可用 → SDK本地缓存 → 恢复后补报；采集服务过载 → 消息队列削峰
• 报表查询
  • Given：数据已入库
  • When：用户打开报表页面或执行自定义查询
  • Then：查询ClickHouse聚合数据 → 缓存结果 → 返回可视化图表
  • And：复杂查询异步执行 → 完成后通知
  • 失败路径：查询超时 → 建议缩小时间范围或简化查询条件

---

16. Design a Content Moderation System

第1层：用户层

• 谁在用？ 平台运营/安全团队（审核内容）、普通用户（举报违规）、内容发布者（受审核影响）
• 完成什么任务？ 自动和人工审核用户发布的内容（文字/图片/视频），拦截违规内容
• 成功标准？ 违规内容在发布后秒级被拦截 → 误判率低 → 人工审核效率高 → 支持申诉

第2层：用户故事

1. 用户发布一条帖子 → 系统自动审核 → 通过 → 正常展示
2. 用户发布含敏感词内容 → 自动拦截 → 进入人工队列 → 审核员判定违规 → 删除并通知用户
3. 用户举报某条评论 → 进入审核队列 → 审核员处理
4. 被处罚用户不服 → 提交申诉 → 二次审核 → 维持/撤销处罚
5. 运营查看审核面板 → 看到待审数量、处理速度、违规类型分布

第3层：功能层

• MVP：关键词过滤（黑名单）+ 人工审核队列 + 审核结果（通过/删除/警告）
• 后续：ML模型（文本分类/图片识别/视频帧检测）、用户举报、申诉流程、审核员绩效管理、规则引擎（可配置策略）、批量审核

第4层：数据层

• 名词：审核任务（task_id, content_id, content_type[text/image/video], source[auto/report], status[pending/approved/rejected], reviewer_id, result, reason）、规则（rule_id, type[keyword/regex/ml_model], config, action[block/flag/pass], priority）、申诉（appeal_id, task_id, user_id, reason, status, reviewer_id）、举报（report_id, reporter_user_id, content_id, reason）
• 关系：一条内容可有多个审核任务（多次审核/申诉）；规则按优先级匹配；举报触发审核任务
• 必须保存：审核记录（合规审计）、规则配置、申诉记录
• 展示用：审核队列、统计面板

第5层：流程层

• 自动审核
  • Given：用户发布内容，审核规则已配置
  • When：内容发布事件触发审核
  • Then：入审核队列 → 规则引擎按优先级执行：关键词匹配 → ML模型打分 → 综合判定置信度
  • And：高置信通过 → 直接放行；高置信违规 → 自动删除/限流并通知用户；低置信 → 进入人工审核队列
  • 失败路径：ML服务不可用 → 降级为关键词过滤 + 全部进人工队列
• 人工审核
  • Given：任务在人工队列中
  • When：审核员领取任务
  • Then：查看内容 → 判定（通过/违规/需更多信息）→ 选择违规类型 → 执行动作 → 记录结果
  • And：批量审核模式（快速键盘操作）
  • 失败路径：审核员之间判定不一致 → 升级到高级审核员
• 申诉处理
  • Given：用户内容被判定违规
  • When：用户提交申诉并说明理由
  • Then：创建申诉任务 → 分配给不同审核员（回避原审核员）→ 重新审核 → 维持或撤销
  • 失败路径：恶意申诉（频繁申诉同一内容）→ 限制申诉频率

---

17. Design a Hotel Reservation System

第1层：用户层

• 谁在用？ 旅客（预订房间）、酒店管理员（管理房态和订单）
• 完成什么任务？ 旅客搜索并预订酒店房间；酒店管理房间可用性和价格
• 成功标准？ 搜索城市+日期 → 看到可用酒店/房型 → 下单预订 → 不超卖

第2层：用户故事

1. 旅客选择城市、入住/退房日期 → 搜索 → 看到可用酒店列表（价格、评分、图片）
2. 旅客选择酒店和房型 → 看到该日期段可用房间数 → 填写信息 → 支付 → 确认预订
3. 旅客查看”我的订单” → 可以取消预订（在取消政策内免费）
4. 酒店管理员设置房型价格 → 调整可用房间数 → 查看订单列表

第3层：功能层

• MVP：酒店/房型搜索（按城市+日期）、查看可用性、下单预订、订单管理
• 后续：支付集成、取消/退款、动态定价、用户评价、推荐、地图视图

第4层：数据层

• 名词：酒店（hotel_id, name, city, address, rating, images）、房型（room_type_id, hotel_id, name, price, capacity）、库存（room_type_id, date, total, booked）、订单（order_id, user_id, room_type_id, check_in, check_out, status, total_price）
• 关系：酒店有多种房型；房型按日期有库存；订单关联用户和房型
• 必须保存：库存（防超卖！）、订单、酒店信息
• 展示用：搜索结果排序、价格日历

第5层：流程层

• 搜索可用酒店
  • Given：用户选择了城市和日期范围
  • When：点击搜索
  • Then：查询该城市酒店 → 对每个酒店检查日期范围内每天是否有库存 → 返回有房的酒店和最低价
• 预订
  • Given：用户选择了房型，日期范围有库存
  • When：确认并支付
  • Then：加锁 → 再次检查库存 → 扣减每天的库存 → 创建订单 → 释放锁 → 发送确认邮件
  • 失败路径：库存不足 → 提示”已被预订”；支付失败 → 回滚库存扣减
• 取消预订
  • Given：订单在可取消期限内
  • When：用户点击取消
  • Then：更新订单状态 → 恢复每天库存 → 触发退款
  • 失败路径：超过取消期限 → 提示”不可取消”或扣除费用

---

18. Design an E-commerce Platform

第1层：用户层

• 谁在用？ 买家（浏览购物）、卖家（管理商品和订单）、平台运营（管理活动和规则）
• 完成什么任务？ 买家发现商品、下单购买、收货评价；卖家上架商品、处理订单、发货
• 成功标准？ 商品搜索精准 → 下单支付流畅 → 库存准确不超卖 → 物流可追踪 → 售后有保障

第2层：用户故事

1. 买家搜索”蓝牙耳机” → 看到商品列表（价格/销量/评分排序）→ 点击查看详情
2. 买家选择规格（颜色/型号）→ 加入购物车 → 继续逛 → 再加一件
3. 买家打开购物车 → 选中商品 → 使用优惠券 → 提交订单 → 选择支付方式 → 支付成功
4. 卖家收到新订单 → 确认 → 打包发货 → 填写物流单号
5. 买家查看物流轨迹 → 确认收货 → 评价商品
6. 买家申请退款/退货 → 卖家处理 → 平台介入仲裁

第3层：功能层

• MVP：商品列表/详情 + 购物车 + 下单 + 支付（接入第三方）+ 订单管理
• 后续：搜索（Elasticsearch）、推荐、优惠券/促销、物流跟踪、评价系统、客服、卖家后台、数据分析、秒杀、分销

第4层：数据层

• 名词：商品（product_id, name, description, images[], category_id, seller_id）、SKU（sku_id, product_id, attributes{color, size}, price, stock）、购物车（user_id, items[{sku_id, quantity}]）、订单（order_id, user_id, items[], total_amount, status[pending/paid/shipped/delivered/cancelled/refunded], created_at）、物流（logistics_id, order_id, carrier, tracking_no, events[]）、评价（review_id, order_id, sku_id, user_id, rating, content, images[]）
• 关系：商品有多个SKU（规格组合）；购物车属于用户包含多个SKU；订单包含多个SKU；订单关联物流信息
• 必须保存：SKU库存（核心！防超卖）、订单（状态机）、支付记录
• 展示用：商品搜索结果、推荐列表、物流轨迹

第5层：流程层

• 下单流程
  • Given：买家已选择商品，购物车有商品
  • When：提交订单
  • Then：校验库存 → 锁定库存（Redis预扣减或数据库乐观锁）→ 计算价格（原价-优惠券-促销）→ 创建订单（状态：待支付）→ 跳转支付
  • And：订单30分钟未支付 → 自动取消 → 释放库存
  • 失败路径：库存不足 → 提示”库存不足，请修改数量”；优惠券不可用 → 提示原因
• 支付回调
  • Given：订单状态为”待支付”
  • When：支付平台回调通知支付成功
  • Then：验签 → 更新订单状态为”已支付” → 正式扣减库存 → 通知卖家 → 发送买家确认
  • 失败路径：重复回调 → 幂等处理（检查订单状态）；验签失败 → 拒绝并告警
• 订单状态机
  • 待支付 → 已支付 → 已发货 → 已收货 → 已评价
  • 待支付 → 已取消（超时/主动取消）
  • 已支付 → 退款中 → 已退款
  • 已发货 → 退货中 → 已退货退款
  • 失败路径：状态流转非法 → 拒绝操作并记录日志

---

19. Design a Payment System

第1层：用户层

• 谁在用？ 消费者（付款）、商户（收款）、平台运营（管理渠道和对账）
• 完成什么任务？ 安全可靠地完成在线支付；支持多种支付渠道；资金流转准确可追溯
• 成功标准？ 支付成功率高 → 资金零差错 → 支持多渠道（微信/支付宝/银行卡）→ 退款及时

第2层：用户故事

1. 消费者在收银台选择支付方式（微信支付）→ 跳转/扫码 → 输入密码 → 支付成功 → 返回商户页面
2. 商户查看账单 → 看到每笔交易明细和结算金额
3. 消费者申请退款 → 商户确认 → 原路退回
4. 运营每日对账 → 系统自动比对平台记录和渠道记录 → 发现差异 → 标记待处理

第3层：功能层

• MVP：收银台（统一支付入口）+ 渠道对接（至少一个，如微信支付）+ 支付单管理 + 回调处理
• 后续：多渠道（支付宝、银行卡、Apple Pay）、退款、分账（平台抽佣）、自动对账、风控（异常交易检测）、商户管理、结算

第4层：数据层

• 名词：支付单（pay_order_id, merchant_order_id, amount, currency, channel, status[created/paying/success/failed/refunded], idempotency_key, created_at）、渠道配置（channel_id, name, api_key, api_secret, callback_url, enabled）、退款单（refund_id, pay_order_id, amount, status, reason）、流水（ledger_id, pay_order_id, type[debit/credit], amount, balance_after, created_at）、对账记录（date, channel, platform_total, channel_total, diff, status）
• 关系：一个商户订单对应一个支付单；支付单关联一个渠道；支付单可有多个退款单；每笔操作产生流水
• 必须保存：支付单（幂等键！）、流水（审计+对账）、渠道配置
• 展示用：交易明细、对账报表

第5层：流程层

• 发起支付
  • Given：用户在商户页面选择了商品，商户调用支付API
  • When：创建支付请求（传入金额、渠道、幂等键）
  • Then：检查幂等键（防重复创建）→ 创建支付单（状态：created）→ 调用渠道API获取支付链接/二维码 → 返回给前端 → 用户完成支付操作
  • 失败路径：渠道API调用失败 → 降级到备用渠道或提示”请稍后重试”
• 支付回调
  • Given：用户在渠道端完成支付
  • When：渠道服务器异步通知回调
  • Then：验签（确认来源可信）→ 检查支付单状态（幂等：已成功则忽略）→ 更新状态为success → 记录流水 → 通知商户系统
  • And：如果回调未到 → 定时轮询渠道查询支付结果
  • 失败路径：验签失败 → 拒绝并告警；金额不匹配 → 标记异常
• 退款
  • Given：支付单状态为success
  • When：商户或用户发起退款
  • Then：创建退款单 → 检查可退金额 → 调用渠道退款API → 等待渠道回调 → 更新退款单和支付单状态 → 记录流水
  • 失败路径：渠道退款失败 → 重试 → 多次失败 → 人工处理

---

20. Design a Flash Sale System

第1层：用户层

• 谁在用？ 消费者（抢购商品）、运营人员（配置活动）
• 完成什么任务？ 在限定时间内以优惠价抢购限量商品；系统承受瞬间流量洪峰不崩溃
• 成功标准？ 库存准确（不超卖不少卖）→ 系统扛住百万QPS → 用户体验公平 → 整体延迟<500ms

第2层：用户故事

1. 运营创建秒杀活动：商品A，100件，明天10:00开始，限价99元 → 保存
2. 用户提前进入活动页 → 看到倒计时 → 10:00到 → 点击”立即抢购” → 看到”抢购成功，请在10分钟内支付”
3. 用户手慢 → 点击抢购 → 看到”已售罄”
4. 用户抢购成功但10分钟内未支付 → 订单自动取消 → 库存回补

第3层：功能层

• MVP：秒杀活动配置（商品/数量/时间）+ 限时抢购页面 + Redis库存扣减 + 订单创建
• 后续：排队机制（令牌/虚拟队列）、验证码/滑块（防机器人）、限购（每人限1件）、预热（缓存加载）、降级方案（静态化兜底）、流量削峰（消息队列）

第4层：数据层

• 名词：秒杀活动（sale_id, product_id, sale_price, total_stock, start_time, end_time, status）、库存令牌（Redis: sale:{id}:stock = 剩余数量）、秒杀订单（order_id, sale_id, user_id, status[pending_payment/paid/cancelled], created_at）、限购记录（Redis: sale:{id}:user:{uid} = 已购数量）
• 关系：一个活动对应一个商品和库存；一个用户在一个活动中最多一个订单
• 必须保存：订单、支付记录
• 展示用：活动页面（倒计时、剩余库存）、排队进度

第5层：流程层

• 秒杀预热
  • Given：活动即将开始（如提前5分钟）
  • When：预热任务触发
  • Then：将库存数量写入Redis → 静态页面CDN预热 → 活动页面切换为”即将开始”状态
  • 失败路径：Redis写入失败 → 告警并手动处理
• 抢购请求
  • Given：活动已开始，用户点击”抢购”
  • When：请求到达服务端
  • Then：限流检查（令牌桶/滑动窗口）→ 限购检查（Redis SETNX user限购key）→ Redis DECR库存 → 返回值>=0表示成功 → 发消息到队列 → 异步创建订单 → 返回”抢购成功”
  • And：库存扣减和限购检查用Lua脚本保证原子性
  • 失败路径：限流拒绝 → 返回”系统繁忙，请重试”；库存<=0 → 返回”已售罄”；限购超限 → 返回”每人限购1件”
• 订单超时取消
  • Given：抢购订单已创建，状态为待支付
  • When：10分钟内未完成支付
  • Then：延迟队列触发 → 检查订单状态仍为待支付 → 取消订单 → Redis INCR回补库存
  • 失败路径：取消时发现已支付（并发场景）→ 忽略取消操作

---

21. Design Proximity Service

第1层：用户层

• 谁在用？ 移动App用户（找附近的餐厅/加油站/商铺）
• 完成什么任务？ 基于当前位置发现附近的商家/地点
• 成功标准？ 输入当前位置+搜索半径 → 快速返回附近结果 → 按距离排序

第2层：用户故事

1. 用户打开App → 授权定位 → 看到附近餐厅列表（按距离排序）
2. 用户点击某餐厅 → 看到详情（地址、评分、营业时间）
3. 商家注册入驻 → 填写地址 → 系统将其转为坐标 → 出现在附近搜索中

第3层：功能层

• MVP：基于经纬度搜索附近商家（给定半径）、商家注册/管理信息
• 后续：按类别筛选、评分排序、导航集成、实时营业状态

第4层：数据层

• 名词：商家（business_id, name, category, latitude, longitude, address, rating, hours）、地理索引（GeoHash / QuadTree）
• 关系：商家拥有一个坐标位置；类别包含多个商家
• 必须保存：商家信息、坐标
• 展示用：距离计算结果、地图标注

第5层：流程层

• 附近搜索
  • Given：用户已授权定位
  • When：用户发起搜索（传入经纬度 + 半径）
  • Then：用GeoHash/QuadTree索引查找范围内商家 → 计算精确距离 → 按距离排序返回
  • 失败路径：半径内无结果 → 自动扩大搜索范围或提示”附近暂无”
• 商家入驻
  • Given：商家提供地址
  • When：提交注册
  • Then：地址 → 地理编码转坐标 → 存入数据库并更新地理索引
  • 失败路径：地址无法识别 → 让商家手动标注地图坐标

---

22. Design Google Maps

第1层：用户层

• 谁在用？ 普通用户（导航/找路）、开发者（嵌入地图API）
• 完成什么任务？ 查看地图、搜索地点、规划路线、实时导航
• 成功标准？ 地图加载快 → 搜地点秒出结果 → 路线规划准确 → 导航实时更新

第2层：用户故事

1. 用户打开地图 → 看到当前位置周边地图 → 缩放/拖动浏览
2. 用户搜索”星巴克” → 地图上标出附近星巴克位置
3. 用户输入目的地 → 系统规划出驾车/步行/公交路线 → 显示预计时间
4. 用户开始导航 → 实时显示位置、路线、预计到达时间 → 遇堵车自动改道

第3层：功能层

• MVP：地图瓦片渲染（缩放/拖动）、地点搜索、路线规划（最短路径）
• 后续：实时导航、实时路况、多交通方式、地点详情/评论、离线地图、街景

第4层：数据层

• 名词：地图瓦片（tile_id, zoom_level, x, y, image_data）、地点/POI（place_id, name, category, lat, lng）、路网（node_id, lat, lng, edges[]）、路线（route_id, waypoints, distance, duration, steps）、路况（road_segment_id, speed, congestion_level, timestamp）
• 关系：路网是图结构（节点+边）；地图按zoom级别分层瓦片；地点标注在地图上
• 必须保存：路网数据、地图瓦片、POI数据
• 展示用：渲染后的地图、路线叠加层

第5层：流程层

• 地图浏览
  • Given：用户打开地图
  • When：拖动/缩放
  • Then：根据当前视口和zoom级别 → 从CDN/缓存加载对应瓦片 → 拼接渲染
• 路线规划
  • Given：用户输入起点和终点
  • When：选择交通方式并请求规划
  • Then：在路网图上用Dijkstra/A*算法计算最优路径 → 考虑实时路况加权 → 返回路线+预计时间
  • And：提供备选路线
  • 失败路径：起点/终点不可达 → 提示”无法规划路线”

---

23. Design Uber/滴滴

第1层：用户层

• 谁在用？ 乘客（叫车出行）、司机（接单赚钱）、平台运营（管理定价和规则）
• 完成什么任务？ 乘客随时叫车并安全到达目的地；司机高效接单并获得报酬
• 成功标准？ 叫车后短时间内匹配到司机 → 价格合理透明 → 导航准确 → 支付自动完成 → 安全有保障

第2层：用户故事

1. 乘客输入目的地 → 看到预估价格和到达时间 → 确认叫车
2. 系统匹配附近司机 → 司机接单 → 乘客看到司机位置实时移动 → 司机到达上车点
3. 乘客上车 → 导航行驶 → 到达目的地 → 自动计费 → 自动支付
4. 乘客给司机评分 → 司机给乘客评分
5. 高峰期 → 系统显示动态加价倍数 → 乘客确认接受 → 加价叫车

第3层：功能层

• MVP：叫车 + 司机匹配（附近接单）+ 实时位置追踪 + 导航 + 计费支付
• 后续：拼车、动态定价（供需调节）、预约叫车、多车型（快车/专车/豪华）、评价系统、安全（行程分享/紧急联系人/录音）、司机奖励体系

第4层：数据层

• 名词：行程（trip_id, rider_id, driver_id, pickup_location, dropoff_location, status[requesting/matched/in_progress/completed/cancelled], fare, created_at）、司机位置（driver_id, lat, lng, heading, speed, timestamp, status[online/busy/offline]）、定价规则（city_id, base_fare, per_km, per_min, surge_multiplier）、评价（trip_id, rater_id, ratee_id, score, comment）
• 关系：行程关联一个乘客和一个司机；司机实时上报位置；定价按城市配置
• 必须保存：行程记录、支付记录、司机位置历史（安全审计）
• 展示用：实时地图（司机位置）、行程轨迹回放、费用明细

第5层：流程层

• 叫车与匹配
  • Given：乘客已输入目的地，附近有在线司机
  • When：乘客确认叫车
  • Then：创建行程请求 → 用GeoHash查找附近空闲司机（如3km内）→ 按距离/评分/接单率排序 → 向最优司机推送请求 → 司机接单
  • And：司机未响应（15秒超时）→ 推送给下一位司机；动态定价时先计算surge倍数
  • 失败路径：附近无可用司机 → 扩大搜索范围 → 仍无 → 提示”暂无车辆，请稍后再试”
• 行程进行中
  • Given：司机已接单
  • When：司机App每2-3秒上报GPS位置
  • Then：更新司机位置 → 乘客端实时显示司机移动 → 到达上车点通知乘客 → 开始行程 → 实时导航 → 到达目的地
  • And：实时计费（基础费 + 里程费 + 时长费 + 动态加价）
  • 失败路径：GPS信号丢失 → 使用最后已知位置 + 路网推算；司机偏离路线 → 重新规划
• 行程结束与支付
  • Given：到达目的地，司机点击”结束行程”
  • When：行程结束
  • Then：计算最终费用 → 自动从乘客支付方式扣款 → 记录流水 → 通知双方 → 进入评价流程
  • 失败路径：支付失败 → 标记待支付 → 提醒乘客更换支付方式

---

24. Design Food Delivery（外卖平台）

第1层：用户层

• 谁在用？ 消费者（点外卖）、商家/餐厅（接单出餐）、骑手（取餐配送）、平台运营
• 完成什么任务？ 消费者在线点餐并收到配送；商家高效出餐；骑手准时送达
• 成功标准？ 下单到送达时间可控 → ETA预估准确 → 三方协调顺畅 → 配送实时可追踪

第2层：用户故事

1. 消费者打开App → 看到附近商家列表（按距离/评分/预计送达时间排序）→ 选择一家餐厅
2. 消费者浏览菜单 → 选择菜品和规格 → 加入购物车 → 使用优惠券 → 下单支付
3. 商家收到订单 → 确认接单 → 开始备餐 → 标记”已出餐”
4. 平台派单给骑手 → 骑手到商家取餐 → 配送中 → 消费者实时看到骑手位置
5. 骑手到达 → 消费者确认收餐 → 评价商家和骑手

第3层：功能层

• MVP：商家列表/菜单浏览 + 购物车/下单 + 商家接单 + 骑手配送 + 实时位置追踪
• 后续：搜索推荐、优惠券/满减、ETA预估（ML模型）、智能派单（最优骑手匹配）、拼单、预约配送、评价、客服/纠纷处理

第4层：数据层

• 名词：商家（merchant_id, name, address, lat, lng, business_hours, rating, categories[]）、菜品（item_id, merchant_id, name, price, description, image, options[{name, choices[]}]）、订单（order_id, user_id, merchant_id, rider_id, items[], total_amount, status[placed/accepted/preparing/ready/picked_up/delivering/delivered/cancelled], eta, created_at）、骑手（rider_id, name, lat, lng, status[idle/picking_up/delivering], current_orders[]）
• 关系：商家有多个菜品；订单关联消费者+商家+骑手（三方）；骑手可同时配送多单
• 必须保存：订单（三方协调核心）、骑手位置轨迹、支付记录
• 展示用：实时骑手位置、ETA倒计时、配送轨迹回放

第5层：流程层

• 下单流程
  • Given：消费者已选好菜品
  • When：提交订单并支付
  • Then：创建订单 → 通知商家 → 商家确认接单（超时未接→自动取消退款）→ 开始备餐
  • 失败路径：商家已打烊 → 提示不可下单；支付失败 → 订单未创建
• 智能派单
  • Given：商家已接单，开始备餐
  • When：系统触发派单（接单后或预计出餐前N分钟）
  • Then：计算附近空闲骑手 → 综合考虑：骑手位置、当前已接单数、商家出餐时间、配送距离 → 选择最优骑手 → 推送 → 骑手接单
  • And：骑手可同时配送多单（顺路合并）
  • 失败路径：无空闲骑手 → 扩大范围 → 仍无 → 延迟派单并通知消费者
• 配送追踪
  • Given：骑手已取餐，开始配送
  • When：骑手App每3秒上报GPS位置
  • Then：更新骑手位置 → 消费者端实时显示地图上的骑手移动 → 计算动态ETA → 到达后通知消费者取餐
  • 失败路径：骑手长时间未移动 → 系统提醒骑手 → 超时未响应 → 转派其他骑手

---

25. Design Google Drive

第1层：用户层

• 谁在用？ 个人用户（存文件）、团队（协作共享）
• 完成什么任务？ 上传/下载文件、管理文件夹、分享文件给他人、多人协作编辑
• 成功标准？ 文件可靠存储不丢失 → 多端同步 → 分享权限精细控制

第2层：用户故事

1. 用户上传一个PDF → 在”我的文件”中看到 → 在手机上也能看到
2. 用户创建文件夹 → 把文件拖入 → 右键分享 → 输入同事邮箱 → 设置”可编辑” → 同事收到通知
3. 用户修改一个文件 → 另一台设备自动同步最新版本
4. 用户误删文件 → 在回收站找到 → 恢复

第3层：功能层

• MVP：文件上传/下载、文件夹管理、文件列表浏览
• 后续：分享与权限、多端同步、版本历史、回收站、大文件分块上传、全文搜索

第4层：数据层

• 名词：用户、文件（file_id, name, size, type, storage_path, parent_folder_id, owner_id, updated_at）、文件夹（folder_id, name, parent_folder_id）、分享记录（file_id, shared_with_user_id, permission）、版本（file_id, version_num, storage_path, created_at）
• 关系：文件夹树形结构（父子）；用户拥有多个文件；文件有多个版本；文件可分享给多个用户
• 必须保存：文件内容、元数据、权限关系、版本历史
• 展示用：存储空间使用量

第5层：流程层

• 上传文件
  • Given：用户已登录，在某个文件夹下
  • When：选择文件上传
  • Then：大文件分块上传 → 存入对象存储 → 写入元数据 → 刷新文件列表
  • And：触发其他设备同步通知
  • 失败路径：存储空间不足 → 提示升级；上传中断 → 支持断点续传
• 分享文件
  • Given：用户拥有该文件
  • When：输入对方邮箱并选择权限
  • Then：创建分享记录 → 发送通知邮件 → 对方在”共享”列表看到该文件
  • 失败路径：邮箱不存在 → 提示错误

---

26. Design Google Docs

第1层：用户层

• 谁在用？ 团队成员（协同写文档）、个人用户（在线编辑）、学生/教师（作业协作）
• 完成什么任务？ 多人同时编辑同一文档，实时看到彼此的修改；管理文档版本
• 成功标准？ 多人同时编辑不冲突 → 修改实时可见（<500ms）→ 不丢失任何人的编辑 → 可回溯历史版本

第2层：用户故事

1. 用户A创建文档 → 输入内容 → 分享给B和C
2. A和B同时编辑同一段落 → 两人的修改实时合并显示 → 无冲突
3. 用户看到其他人的光标位置和选中高亮 → 知道谁在编辑哪里
4. 用户添加评论 → 指定同事 → 同事收到通知 → 回复评论 → 标记已解决
5. 用户查看版本历史 → 看到每次修改的作者和时间 → 可回退到任意版本

第3层：功能层

• MVP：富文本编辑器 + 实时协同（两人以上同时编辑）+ 自动保存
• 后续：评论/建议模式、版本历史、权限管理（查看/评论/编辑）、离线编辑 + 上线同步、模板、导出（PDF/Word）、光标同步

第4层：数据层

• 名词：文档（doc_id, title, owner_id, content_snapshot, version）、操作日志（op_id, doc_id, user_id, operation{type, position, content}, timestamp, version）、版本快照（doc_id, version, content, created_at）、评论（comment_id, doc_id, anchor_position, user_id, content, status[open/resolved]）、协作者（doc_id, user_id, permission[view/comment/edit]）
• 关系：文档有多个协作者；文档有一条操作日志流（有序）；文档按版本有快照
• 必须保存：操作日志（OT/CRDT的操作序列）、版本快照（定期）、评论
• 展示用：实时渲染文档、光标位置、版本对比diff

第5层：流程层

• 实时协同编辑
  • Given：多个用户打开同一文档，各自建立WebSocket连接
  • When：用户A输入一个字符
  • Then：客户端生成操作（如insert(“H”, pos=5)）→ 发送到服务端 → 服务端用OT（Operational Transformation）或CRDT算法转换操作解决冲突 → 广播转换后的操作给所有其他客户端 → 各客户端应用操作更新本地文档
  • And：每N次操作生成一个快照用于快速加载和版本历史；光标位置同步广播
  • 失败路径：WebSocket断开 → 本地缓存操作 → 重连后发送缓存操作 → 服务端合并
• 版本历史
  • Given：文档有多个版本快照
  • When：用户查看版本历史
  • Then：展示版本列表（时间+作者）→ 用户选择版本 → 显示该版本内容 → 可选择回退
  • And：回退创建新版本（不删除历史）
  • 失败路径：快照之间间隔大 → 通过操作日志重放精确还原任意时刻
• 离线编辑
  • Given：用户网络断开
  • When：用户继续编辑文档
  • Then：所有操作存储在本地 → 网络恢复后与服务端同步 → OT/CRDT自动合并
  • 失败路径：离线时间过长导致操作积压 → 同步可能耗时较长 → 显示同步进度

---

27. Design Dropbox

第1层：用户层

• 谁在用？ 个人用户（多设备文件同步）、团队（共享文件夹协作）
• 完成什么任务？ 文件在多台设备间自动同步；文件安全备份到云端
• 成功标准？ 本地修改文件 → 其他设备自动同步 → 同步快速且省带宽 → 冲突可处理

第2层：用户故事

1. 用户在电脑A修改一个文件 → 保存 → 电脑B自动出现最新版本
2. 用户新建文件到同步文件夹 → 自动上传到云端 → 手机上也能看到
3. 用户在电脑A和电脑B同时修改同一文件 → 检测到冲突 → 生成冲突副本并提示用户
4. 用户查看文件历史版本 → 选择某个旧版本恢复
5. 用户选择”选择性同步” → 只同步指定文件夹到本地，节省磁盘空间

第3层：功能层

• MVP：文件上传/下载 + 本地文件夹监控 + 自动同步（全量）
• 后续：增量同步（分块传输变更部分）、版本历史、分享链接、冲突处理、选择性同步、智能同步（按需下载，本地只存占位符）、团队共享文件夹、LAN同步（局域网加速）

第4层：数据层

• 名词：文件元数据（file_id, path, size, content_hash, version, modified_at, is_deleted）、分块（chunk_id, file_id, offset, size, hash, storage_url）、同步状态（device_id, file_id, local_hash, remote_hash, sync_status[synced/pending/conflict]）、变更日志（change_id, file_id, device_id, action[create/modify/delete/rename], timestamp）
• 关系：文件由多个分块组成；每台设备维护自己的同步状态；变更日志记录所有操作
• 必须保存：文件分块（去重存储）、元数据、变更日志
• 展示用：同步状态图标（已同步/同步中/冲突）、存储用量

第5层：流程层

• 文件同步（上传）
  • Given：本地文件发生变更，同步客户端运行中
  • When：文件系统监听（FSEvents/inotify）检测到变更
  • Then：计算文件hash → 与服务端版本对比 → 有变化 → 将文件分块 → 对每块计算hash → 只上传服务端没有的块（去重+增量）→ 更新文件元数据 → 通知其他设备
  • And：上传使用断点续传；大文件分块并行上传
  • 失败路径：网络中断 → 暂停上传 → 恢复后继续
• 文件同步（下载）
  • Given：其他设备上传了新版本
  • When：服务端通过长轮询/WebSocket通知本设备有变更
  • Then：拉取变更列表 → 下载新增/修改的分块 → 在本地重组文件 → 更新同步状态
  • 失败路径：本地文件也被修改（冲突）→ 生成冲突副本文件（如”文件名 (冲突副本 2026-03-30).docx”）→ 提示用户手动处理
• 增量同步
  • Given：大文件只有部分内容被修改
  • When：检测到文件变更
  • Then：对文件按固定大小分块 → 计算每块hash → 与服务端块hash对比 → 只上传变化的块 → 服务端合并重组
  • 失败路径：文件频繁修改 → 聚合变更（等待写入稳定后再同步）

---

28. Design Real-time Gaming Leaderboard

第1层：用户层

• 谁在用？ 游戏玩家、游戏运营
• 完成什么任务？ 玩家查看实时排名；运营管理赛季和排行规则
• 成功标准？ 分数更新后排名实时刷新 → 支持百万级玩家 → 查看自己排名和Top N

第2层：用户故事

1. 玩家完成一局游戏 → 分数上报 → 排行榜实时更新
2. 玩家打开排行榜 → 看到Top 100 → 看到自己的排名和分数
3. 玩家查看好友排行榜 → 只显示好友中的排名
4. 赛季结束 → 排行榜存档 → 新赛季重置

第3层：功能层

• MVP：分数上报、全局排行榜（Top N）、查询自己排名
• 后续：好友排行榜、赛季机制、多维排行（按等级/区服）、防作弊

第4层：数据层

• 名词：玩家（player_id, name, score, rank）、排行榜（用Redis Sorted Set：member=player_id, score=分数）、赛季（season_id, start_date, end_date, status）、历史排行存档
• 关系：玩家属于当前赛季排行榜；赛季结束后存档
• 必须保存：玩家分数、赛季存档
• 展示用：实时排名、排名变化趋势

第5层：流程层

• 分数上报
  • Given：玩家完成一局
  • When：客户端上报分数
  • Then：用Redis ZADD更新玩家分数（取最高/累加，视规则而定）→ 排名自动更新（O(logN)）
  • And：防作弊校验（服务端验证分数合理性）
  • 失败路径：分数异常 → 拒绝更新，标记待审核
• 查询排行榜
  • Given：排行榜数据已存在
  • When：玩家请求Top N
  • Then：Redis ZREVRANGE取前N名 → 返回玩家名和分数
• 查询自己排名
  • Given：玩家在排行榜中
  • When：请求自己的排名
  • Then：Redis ZREVRANK获取排名 → ZSCORE获取分数 → 返回
  • 失败路径：玩家未上榜 → 提示”暂无排名”

---

29. Design Online Multiplayer Game

第1层：用户层

• 谁在用？ 游戏玩家（对战/合作）、游戏开发团队（维护服务器）
• 完成什么任务？ 多名玩家在同一游戏世界中实时交互、对战或合作
• 成功标准？ 延迟<50ms → 游戏状态一致 → 不卡顿不掉线 → 反作弊有效 → 匹配公平

第2层：用户故事

1. 玩家点击”开始匹配” → 等待数秒 → 匹配到对手/队友 → 进入游戏房间
2. 游戏开始 → 玩家操作角色（移动/攻击）→ 看到其他玩家的实时动作 → 流畅无延迟
3. 游戏结束 → 显示结果 → 更新积分/排名 → 回到大厅
4. 玩家使用外挂 → 服务端检测到异常行为 → 踢出并封号
5. 断线重连 → 恢复到游戏当前状态继续游玩

第3层：功能层

• MVP：房间创建/加入 + 实时状态同步 + 基础游戏逻辑 + 结算
• 后续：匹配系统（ELO/MMR）、反作弊（服务端权威验证）、回放系统、语音通信、观战模式、跨区域服务器

第4层：数据层

• 名词：玩家（player_id, name, mmr, stats{}）、房间（room_id, players[], game_state, tick_rate, status[waiting/playing/finished]）、游戏状态（snapshot: 所有实体的位置/血量/状态）、操作日志（tick, player_id, input{action, direction, target}）、匹配队列（player_id, mmr, wait_time, region）
• 关系：房间包含多个玩家；每个tick有一组玩家操作和一个状态快照
• 必须保存：操作日志（用于回放和反作弊审计）、玩家积分、比赛结果
• 展示用：实时游戏画面、匹配进度、战绩统计

第5层：流程层

• 匹配
  • Given：玩家点击匹配，进入匹配队列
  • When：匹配服务扫描队列
  • Then：按MMR范围分组 → 考虑等待时间（等越久范围越宽）→ 凑满一局人数 → 创建房间 → 通知所有玩家加入
  • 失败路径：长时间未匹配 → 扩大MMR范围 → 仍无 → 提示”当前在线人数不足”
• 游戏实时同步
  • Given：房间已创建，所有玩家已连接（UDP/WebSocket）
  • When：玩家按下操作（如移动）
  • Then：客户端发送操作到服务端 → 服务端按tick（如60tick/秒）收集所有操作 → 执行游戏逻辑（碰撞/伤害/状态变更）→ 生成新状态 → 广播给所有客户端
  • And：客户端做预测（Client-side Prediction）+ 插值（Interpolation）保证手感流畅
  • 失败路径：丢包 → UDP不保证送达，客户端用上一帧插值平滑；延迟过高 → 服务端做延迟补偿（Lag Compensation）
• 反作弊
  • Given：游戏过程中，服务端为权威（Authoritative Server）
  • When：收到玩家操作
  • Then：服务端验证操作合理性（移动速度是否超上限、伤害是否合理、位置是否瞬移）→ 异常操作忽略并记录 → 累计异常次数超阈值 → 踢出并标记
  • 失败路径：误判 → 申诉通道 → 人工核查操作日志回放

---

30. Design Live Streaming（直播系统）

第1层：用户层

• 谁在用？ 主播（游戏/才艺/带货）、观众（看直播/互动）、平台运营
• 完成什么任务？ 主播实时推流；观众低延迟观看；观众与主播互动（弹幕/礼物）
• 成功标准？ 推流稳定 → 观看延迟<3秒（互动场景<1秒）→ 百万人同时观看不崩 → 弹幕实时显示

第2层：用户故事

1. 主播打开直播App → 设置标题和封面 → 点击开播 → 开始推流
2. 观众在直播列表看到正在直播的主播 → 点击进入 → 看到实时画面 → 发弹幕”666”
3. 观众送一个礼物 → 直播间全体可见特效 → 主播收到虚拟币
4. 观众请求连麦 → 主播同意 → 双方画面同时显示
5. 直播结束 → 自动生成回放 → 观众可回看

第3层：功能层

• MVP：推流（RTMP采集）+ 拉流（HLS/DASH播放）+ 弹幕
• 后续：美颜/滤镜、连麦（低延迟RTC）、礼物系统、回放、多码率自适应、直播间管理（禁言/踢人）、带货（商品卡片）

第4层：数据层

• 名词：直播间（room_id, streamer_id, title, cover_url, status[live/offline], viewer_count, started_at）、弹幕（msg_id, room_id, user_id, content, timestamp）、礼物记录（gift_id, room_id, sender_id, gift_type, amount, timestamp）、流媒体（stream_key, ingest_url, playback_urls{hls, dash, webrtc}）
• 关系：一个主播一个直播间；直播间有弹幕流和礼物流
• 必须保存：礼物记录（涉及资金）、直播录制（回放）
• 展示用：实时画面、弹幕浮层、礼物特效、观看人数

第5层：流程层

• 推流与分发
  • Given：主播点击开播
  • When：客户端采集音视频并推流（RTMP协议）
  • Then：流到达媒体服务器 → 实时转码（多码率：1080p/720p/480p）→ 切片打包（HLS/DASH）→ 分发到CDN边缘节点 → 观众从最近CDN拉流播放
  • And：低延迟场景用WebRTC替代HLS（延迟从3-5秒降到<1秒）
  • 失败路径：推流中断 → 观众看到”主播断开连接” → 主播重新推流自动恢复
• 弹幕系统
  • Given：直播间有观众在线
  • When：观众发送弹幕
  • Then：消息入队（如Redis Pub/Sub或专用消息服务）→ 广播给直播间所有连接的观众 → 客户端渲染弹幕动画
  • And：弹幕先过内容审核（关键词过滤）
  • 失败路径：弹幕量过大（百万观众）→ 采样展示（客户端随机丢弃部分弹幕）；分层广播（多级扇出）
• 礼物系统
  • Given：观众有虚拟币余额
  • When：点击送礼物
  • Then：扣减观众余额 → 记录礼物流水 → 增加主播收入 → 广播礼物特效给直播间全体
  • 失败路径：余额不足 → 提示充值；并发送礼 → 用事务保证余额一致性

---

31. Design Email System

第1层：用户层

• 谁在用？ 所有需要收发邮件的人（个人/企业），应用系统（通知邮件/营销邮件）
• 完成什么任务？ 撰写和发送邮件；接收和阅读邮件；管理邮件（搜索/标签/归档）
• 成功标准？ 邮件可靠送达 → 收件箱加载快 → 垃圾邮件有效过滤 → 附件支持 → 全文搜索

第2层：用户故事

1. 用户撰写邮件 → 填写收件人/主题/正文 → 添加附件 → 发送 → 看到”已发送”
2. 用户打开收件箱 → 看到未读邮件列表 → 点击阅读 → 回复
3. 用户收到垃圾邮件 → 系统自动放入垃圾箱 / 用户手动标记为垃圾
4. 用户搜索”报销” → 找到相关邮件
5. 用户给邮件打标签”重要” → 移到归档文件夹

第3层：功能层

• MVP：收发邮件（SMTP/IMAP）+ 收件箱/已发送/草稿 + 附件 + 基础搜索
• 后续：标签/文件夹管理、垃圾邮件过滤（SpamAssassin/ML）、邮件规则（自动分类）、日历集成、联系人、签名、富文本编辑、邮件追踪（已读回执）

第4层：数据层

• 名词：邮件（email_id, from, to[], cc[], bcc[], subject, body_html, body_text, attachments[{name, size, storage_url}], headers{}, received_at, is_read, labels[]）、联系人（contact_id, name, email, user_id）、标签/文件夹（label_id, name, user_id, type[system/custom]）、邮件规则（rule_id, user_id, conditions[], actions[]）
• 关系：邮件可发给多个收件人；邮件可有多个标签；邮件可有多个附件；用户有多个联系人
• 必须保存：邮件内容和附件、发送/接收记录
• 展示用：收件箱列表、搜索结果、文件夹视图

第5层：流程层

• 发送邮件
  • Given：用户已撰写邮件
  • When：点击发送
  • Then：存入已发送 → SMTP连接 → DNS查询收件人域名的MX记录 → 连接目标邮件服务器 → 投递邮件 → 记录发送状态
  • And：附件先上传到对象存储 → 邮件中包含引用
  • 失败路径：目标服务器拒收 → 退回发件人（bounce email）；临时失败 → 排入重试队列
• 接收邮件
  • Given：外部邮件到达本系统MX服务器
  • When：SMTP连接收到邮件
  • Then：SPF/DKIM/DMARC验证（反伪造）→ 垃圾邮件评分（内容分析+发件人信誉）→ 通过 → 存储邮件 → 应用用户规则（自动标签/分类）→ 推送通知
  • And：附件提取并存储
  • 失败路径：被判定为垃圾邮件 → 放入垃圾箱（不通知）；发件人域名不合法 → 拒收
• 搜索邮件
  • Given：用户邮件已被索引（Elasticsearch）
  • When：用户输入搜索关键词
  • Then：查询倒排索引 → 按相关性+时间排序 → 高亮匹配文本 → 返回结果
  • 失败路径：无匹配 → 建议修改关键词或扩展搜索范围

---

32. Design Calendar System

第1层：用户层

• 谁在用？ 个人用户（管理日程）、团队成员（安排会议）、企业（会议室预订）
• 完成什么任务？ 创建和管理日程事件；邀请他人参加会议；查看自己和他人的空闲时间
• 成功标准？ 日程创建便捷 → 提醒准时 → 会议邀请/回复流畅 → 跨时区正确显示 → 日历可同步

第2层：用户故事

1. 用户创建事件”周会” → 设置时间、地点、重复（每周一）→ 邀请同事 → 同事收到邀请
2. 同事点击”接受” → 事件出现在其日历中 → 事件前15分钟收到提醒
3. 用户查看同事的空闲时间 → 找到大家都空闲的时段 → 安排会议
4. 用户出差到美国 → 日历自动按当地时区显示 → 国内的会议仍显示正确的当地时间
5. 用户取消重复事件的某一次 → 只删除该次，其他不受影响

第3层：功能层

• MVP：事件CRUD + 日/周/月视图 + 提醒通知
• 后续：邀请/RSVP、空闲时间查询（Find a time）、重复事件（RFC 5545 RRULE）、时区处理（含夏令时）、CalDAV/iCal订阅、会议室预订、与邮件集成

第4层：数据层

• 名词：日历（calendar_id, user_id, name, color, timezone）、事件（event_id, calendar_id, title, description, location, start_time, end_time, timezone, recurrence_rule, reminders[]）、参与者（event_id, user_id, email, rsvp_status[pending/accepted/declined/tentative]）、重复事件异常（event_id, original_date, overridden_start, overridden_end, is_cancelled）
• 关系：用户有多个日历；日历包含多个事件；事件有多个参与者；重复事件有异常列表
• 必须保存：事件数据、参与者回复、重复规则
• 展示用：日历视图渲染、空闲/忙碌状态

第5层：流程层

• 创建事件并邀请
  • Given：用户选择了时间段
  • When：填写事件详情并添加参与者
  • Then：创建事件 → 为每个参与者发送邀请（邮件+应用内通知）→ 参与者日历上显示待回复事件
  • And：如果是重复事件 → 解析RRULE → 不实际创建每一次的记录，查询时动态展开
  • 失败路径：时间冲突 → 提示已有事件但仍允许创建
• 空闲时间查询
  • Given：需要安排一个多人会议
  • When：用户输入参与者列表和时间范围
  • Then：查询每个参与者在该范围内的事件 → 计算交集空闲时段 → 排除非工作时间 → 展示可用时段
  • 失败路径：无共同空闲 → 建议扩大时间范围
• 重复事件修改
  • Given：用户有一个重复事件（如每周一10:00）
  • When：用户修改某一次（如3月30日改到11:00）
  • Then：在异常表中添加记录（original_date=3/30, overridden_start=11:00）→ 其他重复不受影响
  • And：用户也可选择”修改此次及以后所有” → 拆分RRULE（原规则加end_date，新建后续规则）
  • 失败路径：时区切换导致重复事件时间偏移 → 所有时间以UTC存储，显示时转换为用户时区

---

33. Design CRM（客户关系管理）

第1层：用户层

• 谁在用？ 销售人员（跟踪客户和商机）、客服（处理客户问题）、管理层（查看销售报表）
• 完成什么任务？ 管理客户信息和销售管道；记录与客户的每次互动；分析销售业绩
• 成功标准？ 客户信息集中管理 → 销售流程可视化 → 互动记录完整 → 报表辅助决策

第2层：用户故事

1. 销售创建联系人（公司名/联系方式/来源）→ 创建商机（预计金额/阶段：潜在客户）
2. 销售跟进客户 → 打电话/发邮件 → 记录活动（通话30分钟，讨论了报价）
3. 销售将商机从”初步沟通”拖到”方案演示” → 再拖到”报价” → “赢单”
4. 管理层查看销售漏斗 → 看到各阶段商机数量和金额 → 预测本月收入
5. 系统自动提醒销售：某客户3天未跟进 → 销售去跟进

第3层：功能层

• MVP：联系人管理 + 商机管道（Kanban看板/列表）+ 活动记录（电话/邮件/会议）
• 后续：自动化工作流（如商机进入”报价”阶段自动发邮件）、报表/仪表盘、邮件集成（自动关联邮件到联系人）、API/Webhook、自定义字段、角色权限、移动端

第4层：数据层

• 名词：联系人（contact_id, name, company, email, phone, source, owner_id, custom_fields{}）、商机（deal_id, contact_id, title, value, stage, probability, expected_close_date, owner_id）、活动（activity_id, contact_id, deal_id, type[call/email/meeting/note], content, date, duration）、管道阶段（stage_id, pipeline_id, name, order, probability）、自动化规则（rule_id, trigger, conditions[], actions[]）
• 关系：联系人可有多个商机；商机属于某个管道阶段；活动关联联系人和/或商机
• 必须保存：联系人、商机、活动记录
• 展示用：销售管道Kanban、漏斗报表、收入预测

第5层：流程层

• 商机推进
  • Given：商机在某个阶段（如”初步沟通”）
  • When：销售拖拽商机到下一阶段（如”方案演示”）
  • Then：更新商机阶段 → 自动更新probability → 触发自动化规则（如发邮件/创建任务）→ 记录阶段变更日志
  • And：如果是最终阶段（赢单/输单）→ 锁定商机 → 更新统计
  • 失败路径：必填字段未填（如赢单必须填实际金额）→ 弹窗要求补充
• 报表生成
  • Given：有商机和活动数据
  • When：管理层查看销售漏斗
  • Then：按阶段聚合商机数量和金额 → 计算转化率 → 按时间维度显示趋势 → 生成收入预测（各阶段金额 * probability）
  • 失败路径：数据不完整（商机金额为0）→ 标注数据质量警告
• 自动化工作流
  • Given：规则已配置（如”商机3天无活动则提醒owner”）
  • When：定时任务扫描或事件触发
  • Then：评估条件 → 满足 → 执行动作（发通知/创建任务/修改字段/发邮件）
  • 失败路径：动作执行失败（如邮件发送失败）→ 重试 → 记录失败日志

---

34. Design Monitoring & Alerting（监控告警）

第1层：用户层

• 谁在用？ 运维/SRE（监控基础设施）、开发者（监控应用性能）、管理层（看SLA大盘）
• 完成什么任务？ 实时采集系统指标，可视化展示，异常时自动告警通知
• 成功标准？ 指标采集全面实时 → Dashboard一目了然 → 告警及时准确（少漏报少误报）→ 支持百万指标

第2层：用户故事

1. 运维在Dashboard看到CPU/内存/磁盘/网络等指标图表 → 一切正常
2. 某服务器CPU持续>90%超过5分钟 → 告警触发 → 值班人员收到Slack/短信通知
3. 值班人员收到告警 → 查看相关Dashboard → 定位到某个容器内存泄漏 → 重启服务 → 告警恢复
4. 开发者创建告警规则：API P99延迟>500ms持续3分钟 → 保存 → 自动监控
5. SRE查看月度SLA报告 → 可用性99.95% → 满足承诺

第3层：功能层

• MVP：指标采集（Agent/SDK）+ 时序数据库存储 + Dashboard图表 + 告警规则和通知
• 后续：日志聚合（ELK）、链路追踪（分布式trace）、ML异常检测（自动基线）、值班排班（PagerDuty式）、告警聚合/降噪（防告警风暴）、SLA报告

第4层：数据层

• 名词：指标（metric_name, tags{host, service, region}, value, timestamp）、告警规则（rule_id, metric_query, condition, threshold, duration, severity, notify_channels[]）、告警事件（alert_id, rule_id, status[firing/resolved], started_at, resolved_at, acknowledged_by）、值班表（schedule_id, users[], rotation_type, timezone）
• 关系：告警规则监控指标查询结果；告警事件由规则触发；值班表决定通知谁
• 必须保存：时序数据（保留策略：高精度保留7天，降采样保留1年）、告警事件记录、规则配置
• 展示用：Dashboard图表、告警列表、SLA报告

第5层：流程层

• 指标采集与存储
  • Given：Agent部署在各服务器/容器上
  • When：Agent每10-15秒采集指标
  • Then：批量推送到采集网关 → 写入时序数据库（Prometheus/VictoriaMetrics）→ 按保留策略自动降采样和过期清理
  • And：应用SDK自行上报自定义指标（如请求延迟、错误率）
  • 失败路径：Agent与采集服务断连 → 本地缓存 → 恢复后补传；时序DB写入过载 → 水平扩展/采样
• 告警评估与通知
  • Given：告警规则已配置
  • When：评估引擎每个评估周期（如每30秒）执行规则
  • Then：执行PromQL/指标查询 → 结果与阈值比较 → 满足条件且持续超过duration → 创建告警事件（状态：firing）→ 查值班表确定通知人 → 发送通知（Slack/邮件/短信/电话）
  • And：告警恢复（条件不再满足）→ 更新状态为resolved → 发送恢复通知
  • 失败路径：告警风暴（大量告警同时触发）→ 告警聚合（按标签分组，只发一条汇总）；通知失败 → 升级到下一级值班人员
• Dashboard查询
  • Given：指标数据已存储
  • When：用户打开Dashboard
  • Then：执行图表对应的查询 → 时序DB返回数据点 → 前端渲染图表 → 自动刷新
  • 失败路径：查询时间范围过大 → 自动降采样显示（牺牲精度换速度）

---

35. Design Stock Trading（股票交易）

第1层：用户层

• 谁在用？ 散户投资者（手机/网页交易）、机构交易员（专业终端）、量化交易者（API接入）
• 完成什么任务？ 查看实时行情；下买入/卖出单；管理持仓和资金
• 成功标准？ 行情实时推送（延迟<100ms）→ 下单到确认<1秒 → 撮合公平（价格/时间优先）→ 资金和持仓零差错

第2层：用户故事

1. 投资者查看某股票实时行情（价格/涨跌/K线/买卖盘口）→ 决定买入
2. 投资者下限价单：买入100股，限价25.50 → 提交 → 看到”委托已提交”
3. 市场价格到达25.50 → 撮合成功 → 通知”成交100股@25.50” → 持仓更新 → 资金扣除
4. 投资者设置止损单：持仓跌到24.00自动卖出 → 价格到24.00 → 自动触发卖出
5. 交易日结束 → 看到当日盈亏、持仓总值、交易明细

第3层：功能层

• MVP：实时行情显示 + 限价单/市价单 + 撮合引擎 + 持仓和资金管理
• 后续：止损/止盈单、K线图表（分时/日K/周K）、期权/期货、量化API、资产分析报表、新闻/公告、社区

第4层：数据层

• 名词：订单（order_id, user_id, symbol, side[buy/sell], type[limit/market/stop], price, quantity, filled_quantity, status[pending/partial/filled/cancelled], created_at）、成交记录（trade_id, order_id, price, quantity, timestamp）、持仓（user_id, symbol, quantity, avg_cost）、账户（user_id, cash_balance, frozen_balance）、行情（symbol, last_price, bid[], ask[], volume, timestamp）
• 关系：一个订单可产生多笔成交（部分成交）；持仓按用户+股票维护；行情按股票实时更新
• 必须保存：订单、成交记录、持仓（严格一致性！）、资金流水
• 展示用：实时行情推送、K线图、盘口、盈亏

第5层：流程层

• 下单
  • Given：投资者有足够资金/持仓
  • When：提交买入/卖出订单
  • Then：风控检查（资金是否足够、持仓是否足够、是否涨跌停限制）→ 冻结资金/持仓 → 创建订单 → 发送到撮合引擎队列
  • 失败路径：风控不通过 → 拒绝并告知原因（资金不足/涨停不可买入等）
• 撮合
  • Given：撮合引擎按股票分区运行，维护买卖盘口（OrderBook）
  • When：新订单进入
  • Then：按价格/时间优先原则匹配对手单 → 有匹配 → 生成成交记录 → 更新双方订单状态 → 更新持仓和资金（解冻+扣减/增加）→ 推送成交通知 → 更新行情
  • And：市价单立即与当前最优对手价成交；限价单挂入盘口等待
  • 失败路径：无对手单 → 限价单挂在盘口等待；市价单无流动性 → 部分成交或取消
• 实时行情推送
  • Given：撮合引擎产生成交
  • When：每笔成交完成
  • Then：更新最新价、成交量 → 推送到行情服务 → 行情服务通过WebSocket广播给所有订阅该股票的客户端
  • And：K线按时间粒度聚合（1分钟K、5分钟K等）
  • 失败路径：推送延迟 → 客户端轮询兜底；行情服务过载 → 采样/限频

---

36. Design Digital Wallet（数字钱包）

第1层：用户层

• 谁在用？ 消费者（支付/转账/管理余额）、商户（收款）
• 完成什么任务？ 安全地存储资金、转账给他人、扫码支付、查看交易记录
• 成功标准？ 资金零差错 → 转账秒到 → 支付体验流畅 → 安全（多因素认证）→ 对账无误

第2层：用户故事

1. 用户充值：选择银行卡 → 输入金额 → 验证身份 → 余额增加
2. 用户转账给朋友：输入对方手机号/扫码 → 输入金额 → 验证支付密码 → 对方秒收到
3. 用户在商店扫码支付 → 输入金额 → 确认 → 支付成功 → 余额扣减
4. 用户查看月度账单 → 看到收支分类和趋势图
5. 用户手机丢失 → 在另一台设备冻结账户 → 资金安全

第3层：功能层

• MVP：充值（银行卡入金）+ 余额管理 + 转账 + 交易记录
• 后续：扫码支付（二维码）、绑定多张银行卡、理财产品、账单分析、多因素认证（指纹/面容/支付密码）、账户冻结/解冻、KYC实名认证

第4层：数据层

• 名词：账户（account_id, user_id, balance, frozen_balance, status[active/frozen], currency）、交易（txn_id, from_account, to_account, amount, type[transfer/topup/payment/refund], status[pending/success/failed], idempotency_key, created_at）、银行卡（card_id, user_id, bank_name, card_number_encrypted, is_default）、流水（ledger_id, account_id, txn_id, type[debit/credit], amount, balance_after, created_at）
• 关系：用户有一个钱包账户；账户有多笔交易；每笔交易产生两条流水（一借一贷）；用户可绑定多张银行卡
• 必须保存：账户余额（强一致！）、交易记录（幂等键）、流水（审计+对账）
• 展示用：余额、交易列表、账单分析图表

第5层：流程层

• 转账
  • Given：用户A要转账给用户B
  • When：输入金额并确认（支付密码/生物识别）
  • Then：验证身份 → 检查A余额>=金额 → 开启事务：A账户扣减余额 + B账户增加余额 + 创建交易记录 + 写入双方流水 → 提交事务 → 通知双方
  • And：使用幂等键防止重复提交；分布式场景用分布式事务或事件驱动最终一致
  • 失败路径：余额不足 → 拒绝并提示；身份验证失败 → 拒绝并记录风险事件；系统异常 → 事务回滚
• 充值（银行卡入金）
  • Given：用户已绑定银行卡
  • When：选择银行卡并输入充值金额
  • Then：调用银行扣款API → 等待回调/轮询结果 → 成功 → 增加钱包余额 → 记录交易和流水
  • 失败路径：银行扣款失败 → 不增加余额 → 提示用户；回调超时 → 轮询确认 → 仍未确认 → 挂起待人工处理
• 对账
  • Given：每日定时任务
  • When：对账任务触发
  • Then：拉取银行/渠道流水 → 与本系统交易记录逐笔比对 → 金额一致标记已对 → 不一致标记差异 → 生成对账报告
  • 失败路径：发现长款（我方多钱）→ 标记待退；发现短款（我方少钱）→ 标记待追 → 告警财务

---

37. Design Push Notification Service

第1层：用户层

• 谁在用？ 移动应用开发者（发推送）、移动App用户（接收推送）、运营人员（营销推送）
• 完成什么任务？ 向移动设备发送推送通知（即使App未打开）；管理推送任务和到达率
• 成功标准？ 推送及时到达 → 支持百万级设备 → 到达率可追踪 → 按平台(iOS/Android)正确分发

第2层：用户故事

1. 运营创建推送任务：标题”限时优惠”→ 选择目标用户（全量/分组/个人）→ 定时明天10:00发送
2. 到达10:00 → 系统向百万设备批量发送 → 用户手机收到推送通知
3. 用户点击推送 → App打开并跳转到对应页面（Deep Link）
4. 运营查看统计 → 发送数、到达数、点击数、点击率
5. 用户在App中关闭某类推送 → 后续不再收到该类通知

第3层：功能层

• MVP：设备令牌注册 + 对接FCM(Android)/APNs(iOS) + 单推/群推 + 发送记录
• 后续：定时推送、分组推送（按标签/用户属性）、A/B测试（不同文案对比点击率）、富媒体推送（图片/按钮）、打开率统计、用户偏好（退订某类通知）、速率控制（避免瞬间压垮FCM/APNs）

第4层：数据层

• 名词：设备令牌（token_id, user_id, platform[ios/android], push_token, app_version, created_at, updated_at）、推送任务（task_id, title, body, deep_link, target_type[all/segment/user_ids], target_config, scheduled_at, status[draft/scheduled/sending/sent]）、发送记录（record_id, task_id, token_id, status[sent/delivered/opened/failed], sent_at, error）、用户偏好（user_id, category, enabled）
• 关系：用户可有多个设备令牌（多设备）；推送任务对应多条发送记录
• 必须保存：设备令牌（核心！过期需更新）、发送记录
• 展示用：推送统计仪表盘（漏斗：发送→到达→打开）

第5层：流程层

• 发送推送
  • Given：推送任务已创建，到达发送时间
  • When：调度器触发发送
  • Then：确定目标用户 → 查询这些用户的设备令牌 → 按平台分组（iOS/Android）→ 批量调用APNs/FCM API（每批1000个令牌）→ 记录每条发送结果
  • And：速率控制（按FCM/APNs限制调整并发数）；失败自动重试（最多3次）
  • 失败路径：令牌失效（APNs返回invalid token）→ 标记令牌无效 → 下次不再发送；FCM/APNs限流 → 退避重试
• 令牌管理
  • Given：用户安装App或更新App
  • When：App启动时向FCM/APNs获取推送令牌
  • Then：将令牌上报到服务端 → 如已存在则更新 → 如新令牌则创建 → 关联用户ID
  • And：用户卸载App → 令牌失效（通过发送失败检测）→ 清理无效令牌
  • 失败路径：用户未授权推送 → 不上报令牌 → 该用户不可推送
• 统计追踪
  • Given：推送已发送
  • When：设备收到推送（FCM delivery receipt）/ 用户点击推送（App上报）
  • Then：更新发送记录状态 → 聚合统计：发送数→到达数→打开数→漏斗
  • 失败路径：FCM不保证delivery receipt → 到达率为估算值

---

38. Design Offline-First App

第1层：用户层

• 谁在用？ 弱网/无网环境的移动用户（如外勤人员、旅行者、偏远地区用户）
• 完成什么任务？ 在无网络时仍能正常使用App（查看和创建数据）；联网时自动同步
• 成功标准？ 离线时核心功能完全可用 → 联网后数据自动同步无丢失 → 冲突有合理的解决策略

第2层：用户故事

1. 外勤人员在地下室（无网络）→ 打开App → 查看之前同步的客户列表 → 创建新的拜访记录
2. 走出地下室（恢复网络）→ App自动将新记录同步到服务器
3. 两个销售同时离线修改了同一客户的电话号码 → 联网后系统检测到冲突 → 提示用户选择保留哪个版本
4. 用户在弱网环境 → App优先使用本地数据 → 后台静默同步

第3层：功能层

• MVP：本地数据库存储（SQLite/Realm）+ 网络状态检测 + 联网时自动同步（推+拉）
• 后续：冲突解决策略（Last Write Wins / 合并 / 用户选择）、增量同步（只同步变更）、选择性同步（按数据类型/范围）、后台同步、同步进度显示、数据压缩

第4层：数据层

• 名词：本地记录（record_id, entity_type, data{}, local_version, remote_version, sync_status[synced/pending/conflict]）、变更日志（change_id, record_id, action[create/update/delete], changed_fields{}, timestamp, device_id）、同步游标（device_id, entity_type, last_sync_timestamp, last_sync_version）
• 关系：每条本地记录有同步状态；变更日志记录所有离线操作；同步游标跟踪同步进度
• 必须保存：本地数据库（设备端）、变更日志（同步依据）
• 展示用：同步状态指示器、冲突解决UI

第5层：流程层

• 离线操作
  • Given：设备无网络连接
  • When：用户创建/修改/删除数据
  • Then：写入本地SQLite → 同时写入变更日志（记录操作类型和变更字段）→ 标记记录sync_status=pending → UI正常响应
  • 失败路径：本地存储满 → 提示清理空间
• 联网同步
  • Given：网络恢复
  • When：检测到联网（或用户主动触发）
  • Then：推送阶段：将pending的变更日志发送到服务器 → 服务器应用变更 → 返回确认 → 本地标记synced
  • And：拉取阶段：从服务器获取自last_sync_timestamp以来的其他设备变更 → 应用到本地 → 更新游标
  • 失败路径：同步中断 → 从游标位置继续（不重复传输）
• 冲突解决
  • Given：本地和服务器对同一记录都有修改
  • When：同步时检测到版本冲突（local_version != expected_remote_version）
  • Then：根据策略处理：
    • Last Write Wins：时间戳较新的覆盖较旧的（自动）
    • 字段级合并：不同字段的修改合并，相同字段冲突则提示用户
    • 用户选择：展示两个版本 → 用户选择保留哪个
  • 失败路径：用户忽略冲突 → 默认LWW → 后续可查看冲突历史恢复

---

39. Design IDE/Code Editor

第1层：用户层

• 谁在用？ 软件开发者（日常写代码）、数据科学家（脚本/Notebook）、学生（学习编程）
• 完成什么任务？ 高效编写、编辑、调试和管理代码
• 成功标准？ 打开大项目秒级就绪 → 编辑流畅不卡顿 → 智能补全精准 → 扩展生态丰富

第2层：用户故事

1. 开发者打开项目文件夹 → 文件树加载 → 打开某个文件 → 语法高亮正确显示
2. 开发者输入代码 → 出现自动补全建议 → 选择 → 补全插入
3. 开发者Ctrl+Click函数名 → 跳转到定义 → 查看实现 → 返回
4. 开发者保存文件 → 看到错误波浪线（诊断）→ 鼠标悬停查看错误信息 → 修复
5. 开发者打开内置终端 → 运行测试 → 在输出中看到结果
6. 开发者安装Python扩展 → 获得Python专属的补全/调试/Lint能力

第3层：功能层

• MVP：文本编辑器（高性能文本缓冲区）+ 语法高亮 + 文件树浏览器 + 基础搜索替换
• 后续：LSP集成（补全/跳转/重构/诊断）、Git集成、内置终端、扩展系统（沙箱运行）、调试器、远程开发（SSH/容器）、AI辅助编码、主题/快捷键自定义、多光标编辑

第4层：数据层

• 名词：文件缓冲区（buffer_id, file_path, content[Rope/PieceTable数据结构], is_modified, language_id）、项目（workspace_path, settings{}, extensions[]）、扩展（extension_id, name, version, manifest, entry_point）、LSP会话（server_id, language, capabilities, process_id）、设置（scope[user/workspace], key, value）
• 关系：项目包含多个文件；文件关联语言和LSP服务器；扩展注册补全/命令/视图等贡献点
• 必须保存：用户设置、工作区配置、扩展列表
• 展示用：编辑器视图、文件树、诊断面板、终端输出

第5层：流程层

• 打开文件并编辑
  • Given：用户打开一个代码文件
  • When：加载文件内容
  • Then：读取文件 → 写入文本缓冲区（Rope/PieceTable结构，支持高效插入/删除）→ 增量解析语法树（Tree-sitter）→ 应用语法高亮 → 渲染可见区域（虚拟滚动，只渲染视口内的行）
  • And：通知LSP服务器文件已打开 → LSP返回诊断信息 → 显示错误/警告波浪线
  • 失败路径：文件过大（>100MB）→ 提示”大文件模式”（禁用高亮和LSP）
• 智能补全
  • Given：LSP服务器已启动并初始化
  • When：用户输入字符（如”.”触发）
  • Then：编辑器发送textDocument/completion请求到LSP → LSP分析上下文 → 返回补全列表 → 编辑器显示补全菜单 → 用户选择 → 插入文本
  • And：显示补全项的文档和类型签名
  • 失败路径：LSP响应慢 → 显示加载中 → 超时则隐藏补全菜单
• 扩展系统
  • Given：用户安装了一个扩展
  • When：编辑器启动或扩展安装后
  • Then：加载扩展manifest → 注册贡献点（命令/菜单/快捷键/语言/视图）→ 在独立进程（Extension Host）中运行扩展代码 → 通过API代理与编辑器通信
  • And：扩展运行在沙箱中，通过有限API访问编辑器功能（不能直接操作文件系统等）
  • 失败路径：扩展崩溃 → Extension Host重启 → 不影响编辑器主进程

---

40. Design Desktop Sync Client

第1层：用户层

• 谁在用？ 云存储服务的桌面端用户（如Dropbox/OneDrive/Google Drive桌面客户端用户）
• 完成什么任务？ 在桌面上像操作本地文件一样使用云端文件；文件变更自动同步
• 成功标准？ 文件变更秒级检测 → 同步可靠不丢文件 → 资源占用低 → 冲突可处理 → 托盘状态一目了然

第2层：用户故事

1. 用户安装客户端 → 登录 → 选择同步文件夹 → 云端文件下载到本地
2. 用户在Finder/Explorer中修改文件 → 保存 → 文件图标变为同步中 → 几秒后变为已同步
3. 另一台电脑上的修改 → 本机自动下载更新 → 文件变为最新版本
4. 用户在托盘看到同步状态（已同步/同步中3个文件/暂停）
5. 用户选择”智能同步” → 不常用文件只显示占位符 → 打开时按需下载

第3层：功能层

• MVP：文件系统监控（检测变更）+ 上传/下载同步 + 托盘状态显示
• 后续：选择性同步（只同步部分文件夹）、智能同步/按需下载（占位符文件）、带宽控制、冲突提示与处理、暂停/恢复同步、LAN同步加速、文件版本查看

第4层：数据层

• 名词：同步状态数据库（file_path, local_hash, remote_hash, local_mtime, remote_mtime, sync_status[synced/uploading/downloading/conflict/ignored]）、变更队列（change_id, file_path, action[create/modify/delete/rename], detected_at, status[pending/processing/done]）、账户配置（user_id, sync_folder_path, selective_sync_rules[], bandwidth_limit）
• 关系：每个文件有一条同步状态记录；变更按队列顺序处理
• 必须保存：同步状态数据库（SQLite本地存储）、账户配置
• 展示用：托盘图标和菜单、文件图标叠加（synced/syncing/conflict）、同步活动日志

第5层：流程层

• 检测本地变更
  • Given：同步客户端运行中，监控同步文件夹
  • When：文件系统事件（macOS FSEvents / Linux inotify / Windows ReadDirectoryChanges）检测到文件变更
  • Then：过滤临时文件和忽略规则 → 等待写入稳定（文件不再被修改，如500ms无新事件）→ 计算文件hash → 与本地数据库对比 → 有变化则加入变更队列
  • And：批量文件操作（如解压缩产生大量文件）→ 聚合后批量处理
  • 失败路径：文件被锁定（其他程序占用）→ 等待解锁 → 超时则标记待重试
• 上传同步
  • Given：变更队列中有待上传文件
  • When：取出变更
  • Then：检查远端是否有更新的版本（防覆盖）→ 无冲突 → 分块上传（只传变更块）→ 更新远端元数据 → 更新本地同步状态 → 托盘显示”已同步”
  • And：大文件断点续传；带宽限制下排队上传
  • 失败路径：远端有更新版本（冲突）→ 下载远端版本 → 保留本地版本为冲突副本 → 提示用户
• 下载同步（远端变更）
  • Given：服务端通知本机有远端变更（长轮询/WebSocket/Server-Sent Events）
  • When：收到变更通知
  • Then：拉取变更列表 → 下载变更文件（增量/分块）→ 写入本地 → 更新同步状态 → 文件图标更新为”已同步”
  • And：智能同步模式：只更新元数据和占位符 → 用户打开文件时才真正下载内容
  • 失败路径：本地也有修改（冲突）→ 生成冲突副本；磁盘空间不足 → 暂停同步并提示