返回模板页

系统设计图示例

下面这些案例展示了工程师如何为常见后端场景绘制架构——从简单的 CRUD 服务到分布式实时系统。可以作为自己设计工作或面试准备的参考。

使用这个系统设计图模板返回模板页
系统设计图示例

真实案例

短链接服务

使用场景: 准备系统设计面试的工程师

客户端 → LB → API 服务（无状态，水平扩展）
写路径：API → MySQL（id, shortCode, originalUrl, userId）
读路径：API → Redis 缓存 → MySQL 兜底
分析：API → Kafka → 点击 Consumer → ClickHouse
短码：自增ID的base62编码

这样组织的原因: 读写分离和旁路缓存模式是这个架构的两个关键设计决策。在图中明确展示它们，让缓存失效和一致性的权衡讨论自然发生。

实时聊天服务

使用场景: 后端工程师，设计消息功能

客户端（WebSocket）→ 网关 → 消息服务
消息服务 → Kafka（扇出到接收方）
推送 Worker → 推送通知服务（离线用户）
消息存储：Cassandra（时序数据，高写入吞吐）
在线状态：Redis（在线/离线状态，TTL过期）
文件附件：S3 + CDN

这样组织的原因: WebSocket 连接在网关层需要会话粘滞路由——这个约束很容易在没有图的情况下被忽略。Cassandra 适合消息时序数据与关系型数据库的权衡也值得标注。

电商结账流程

使用场景: 平台团队，设计可靠的支付流程

客户端 → API 网关 → 订单服务
订单服务 → 库存服务（锁定库存）
订单服务 → 支付服务 → 支付宝/微信支付
订单服务 → 通知服务 → 邮件/短信
Saga 模式处理分布式事务（失败时补偿事务）
订单事件 → Kafka → 分析 + 履约服务

这样组织的原因: Saga 模式是这里最重要的设计决策。在图中明确展示补偿事务，避免了在微服务中假设两阶段提交可行的常见错误。

通知推送系统

使用场景: 工程师，构建多渠道通知服务

生产者服务 → 通知 API → 队列（SQS/Kafka）
分发 Worker：读取队列，检查用户偏好设置
邮件渠道 → SendGrid（限速，去重）
推送渠道 → FCM/APNs
短信渠道 → 短信服务商
送达回执 → DB → 监控仪表盘

这样组织的原因: 分发器模式把生产者和送达渠道解耦。新增渠道（如企业微信）只需要加一个渠道处理器，不需要修改每个生产者——这个扩展性优势在图中一眼可见。

搜索自动补全服务

使用场景: 工程师，设计输入即搜索功能

客户端 → CDN（缓存热门前缀）→ 搜索 API
搜索 API → Trie 服务（内存中，读密集）
Trie 定期重建，数据来源：聚合搜索日志
写路径：点击流 → Kafka → 日志聚合 → Trie 更新器
兜底：ElasticSearch 处理 Trie 中没有的长尾查询

这样组织的原因: 热门前缀用内存 Trie，罕见查询回退到 ElasticSearch，是经典的分层缓存策略。图让新鲜度和延迟之间的权衡讨论自然展开。

视频上传和转码流水线

使用场景: 后端工程师，设计视频平台功能

客户端 → 上传 API → S3（原始视频）
S3 事件 → SQS → 转码 Worker（EC2 Spot/Lambda）
转码：生成 360p、720p、1080p 多规格
输出 → S3（处理后）→ CloudFront CDN
元数据：DynamoDB（videoId, status, formats, thumbnailUrl）
进度更新 → WebSocket → 客户端轮询

这样组织的原因: 用 Spot 实例跑转码 Worker 比按需实例节省约70%成本——一旦异步处理模式在图中可见，这个细节就自然成为值得讨论的设计点。

使用技巧

  • 从最高层次的抽象开始：客户端、服务、数据。只在当前决策需要的地方加入细节。
  • 每条箭头都标明数据流方向——没有方向的线在分布式系统中是歧义的。
  • 在关键路径上标注协议（HTTP/2、gRPC、WebSocket、AMQP），让读者不用开口就知道通信契约。
  • 每个持有状态的组件都应该有标签——有状态的组件驱动了大多数扩展性和可靠性的权衡决策。

在线开始编辑

回到模板页，直接替换成你的课程主题、章节和复习重点，就可以继续使用这套结构。

使用这个模板： /editor/new?template=system-design

使用这个系统设计图模板