系统设计面试遇到开放题怎么办：Booking、Ticket、Payroll 和 Chat 系统的通用框架

系统设计面试遇到开放题怎么办：Booking、Ticket、Payroll 和 Chat 系统的通用框架

系统设计面试最难的不是高频题，而是开放题。面试官可能让你设计 booking system、ticket system、payroll system、chat system、distributed scheduler，甚至只是说“设计一个内部平台”。

这类题通常没有唯一答案。真正考察的是你能不能主动澄清需求、控制范围、识别风险，并选择一个有价值的方向深入。

不要急着画图

开放题最忌讳一上来画一套模板架构。先花 3 到 5 分钟澄清：

• 谁是用户？
• 核心流程是什么？
• 读写比例如何？
• 是否需要实时？
• 一致性要求多高？
• 规模假设是什么？
• 哪些功能是 MVP，哪些是后续扩展？

如果面试官回答很开放，你可以主动提出假设：

“我先把范围限定在核心交易链路，优先保证正确性和可扩展性。报表和运营后台我会作为后续模块讨论。”

这会让面试从发散变成可推进。

Booking System：核心是库存和并发

Booking 类题目常见于房源、酒店、活动、预约等场景。核心问题不是页面怎么展示，而是：

• 如何搜索可用资源
• 如何防止重复预订
• 如何处理支付和超时
• 如何支持取消和退款
• 如何处理价格、库存和可用性的变化

可以设计：

Search Service
Availability Service
Reservation Service
Payment Service
Notification Service

关键 deep dive 是 reservation state machine：

AVAILABLE → HELD → CONFIRMED
HELD → EXPIRED
CONFIRMED → CANCELLED

如果多个用户同时预订同一资源，需要明确一致性策略。可以用数据库唯一约束、事务、乐观锁或库存 hold 机制。不要只说“加锁”，要说明锁的粒度和性能影响。

Ticket System：核心是分配、claim 和指标

Ticket 系统常被设计成客服、内部工单或支持平台。核心流程包括：

• ticket 从 email、API、form 等渠道进入
• 系统根据语言、地区、产品线、优先级打标签
• agent 根据规则查看队列
• agent claim ticket
• manager 查看处理指标

可以设计：

Ingestion Service
Rules Engine
Ticket Store
Assignment / Claim Service
Agent Queue View
Metrics Pipeline

这里的 deep dive 可以选 claim 的并发控制：两个 agent 同时 claim 同一个 ticket，如何保证只有一个成功？可以用条件更新：

UPDATE tickets
SET owner_id = ?
WHERE ticket_id = ? AND owner_id IS NULL

指标部分可以讲 average first response time、average close time、SLA breach rate。这比只做 CRUD 更像完整系统。

Payroll System：核心是正确性和幂等

Payroll 看似业务题，实则考察一致性、批处理和合规。关键问题包括：

• 不同支付频率
• 税务规则
• 地区差异
• 大批量计算
• 发薪日高并发
• 防止重复支付

高层设计可以包括：

Employee Service
Payroll Rule Engine
Tax Calculation Service
Payroll Run Scheduler
Payment Service
Audit Ledger

最重要的是幂等和审计。每次 payroll run 应该有唯一 run_id，每笔 payment 应该有 idempotency key。支付状态要可追踪，失败可以重试，但不能重复打款。

如果面试官追问扩展性，可以把计算拆成 batch jobs，按公司、地区或 pay group 分片。发薪日前预计算，发薪日只执行确认和支付。

Chat / Multi-Agent 系统：核心是流式输出和取消

AI chat 或多 agent 系统的设计重点和普通聊天不同。它通常需要：

• 长任务执行
• loading state
• agent invocation history
• output streaming
• cancellation
• token budget
• failure recovery

高层可以设计：

Chat API
Orchestrator
Agent Workers
Message History Store
Streaming Gateway
Cancellation Controller
Rate / Token Limiter

关键 deep dive 是状态流：

user message received
orchestrator started
agent A started
agent A completed
agent B started
output streaming
completed / cancelled / failed

如果用户取消，系统要停止后续 agent 调用，标记 run 状态，并关闭 stream。已经产生的历史是否保留，也要定义清楚。

Distributed Scheduler：核心是不会漏任务

任务调度器题通常会追问可靠性：

• 任务如何存储
• 如何按时间触发
• worker 宕机怎么办
• 如何避免重复执行
• 如何支持百万级任务

可以设计：

Task Store
Scheduler / Poller
Queue
Workers
Heartbeat / Lease
Retry + Dead Letter Queue

关键是 lease。worker 拿到任务后设置 lease_until，如果 worker 宕机，lease 过期后任务可以被重新领取。任务执行侧最好幂等，因为分布式系统很难绝对保证不重复。

开放题的通用回答结构

你可以用这个模板：

1. Clarify users and core workflow
2. Define scale and consistency assumptions
3. Identify core entities
4. Draw high-level architecture
5. Walk through main flow
6. Pick one or two hard parts to deep dive
7. Discuss failure modes and tradeoffs

不要试图把所有模块讲到同样深。系统设计面试通常需要你选择重点。一个清楚的 deep dive，胜过十个浅层服务名。

结尾

开放型系统设计题考察的是工程判断，不是模板记忆。你要能把模糊题目变成明确问题，把业务流程变成核心实体，把架构图变成可解释的 tradeoff。

如果你系统设计只在见过原题时表现好，一遇到新题就发散，说明需要练的是“澄清和收束能力”。一次高质量 mock 可以帮你训练如何在 45 分钟内从开放题推进到有深度的系统设计答案。你可以在服务和价格页面查看系统设计 mock 和完整面试辅导服务；如果已经有具体面试时间，也可以通过联系我们页面说明目标岗位、面试轮次和准备进度。