AI速通系统设计 — 系统拆解

用「思考框架」的 Step 1（5层分析）逐一拆解每个系统。

---

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 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次）

---

3. 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缓存（或实时聚合）获取最新动态列表，按时间/分数排序返回
  • 失败路径：无关注 → 展示推荐内容/空状态

---

4. 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断开 → 客户端自动重连并拉取缺失消息

---

5. 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：查倒排索引 → 计算相关性分数 → 过滤权限 → 返回排序结果
  • 失败路径：无匹配结果 → 展示”未找到”并建议修改关键词

---

6. 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

---

7. 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：创建分享记录 → 发送通知邮件 → 对方在”共享”列表看到该文件
  • 失败路径：邮箱不存在 → 提示错误

---

8. 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：地址 → 地理编码转坐标 → 存入数据库并更新地理索引
  • 失败路径：地址无法识别 → 让商家手动标注地图坐标

---

9. 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：提供备选路线
  • 失败路径：起点/终点不可达 → 提示”无法规划路线”

---

10. Design 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：更新订单状态 → 恢复每天库存 → 触发退款
  • 失败路径：超过取消期限 → 提示”不可取消”或扣除费用

---

11. 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获取分数 → 返回
  • 失败路径：玩家未上榜 → 提示”暂无排名”