系统设计面里主流程画通只完成了一部分。真正值得往下聊的是某一步没返回时你知不知道事情到底做成了没有。先把这个不确定性讲清楚再谈要不要加重试、队列或缓存。比如设计一个任务提交接口请求进来生成任务交给执行方最后返回任务编号。顺着箭头说一遍很容易。现在把响应丢掉调用方超时了任务却可能已经创建。用户再点一次是找回原任务还是多创建一份超时不是业务结果超时说明调用方在规定时间内没拿到结果不能单凭这一点判断服务端没处理。请求可能没送到也可能处理了一半还可能已经完成只是响应没能回来。三个位置的故障表面相似后续动作却可能不同。因此先给操作分类。重复读取一份任务状态与重复触发一项有副作用的任务不应该直接套同一种策略。前者主要要考虑成本和时效后者还要考虑重复执行会产生什么业务后果。这里的分类取决于具体操作不取决于接口叫什么名字。常见的追问是那就加个唯一请求标识可以吗可以作为方案的一部分但标识要回答完整谁生成、代表哪一次业务意图、重试时是否复用、保存多久、同一标识带着不同参数怎么办。每次重试都生成新标识服务端仍然无法把它们认成同一次提交。把判重和创建之间的缝隙画出来如果方案是「先查标识不存在就创建」再同时放进两个请求。它们有可能都查到不存在然后各创建一份。口头说有去重并没有解释并发时如何阻止重复。接下来可以讨论唯一性约束、原子操作或事务让判定与状态写入之间有明确保证。具体选什么要看存储能力和业务边界面试里至少要指出依赖什么保证。单进程里的一把锁不能自动约束其他实例也在做同一件事。任务写入成功、投递给执行方失败又是另一个缝隙。你可以先把任务状态可靠保存再由后续机制继续投递但这会引入等待、重复投递和恢复时机的问题。队列能改变工作分配方式不会替你定义业务上「完成一次」的含义。重试必须有停下来的地方说「失败就重试」还不够。什么错误值得重试最多试多久每次之间等多长超过预算以后由谁接手参数本身不合法时原样重复通常不能修好它暂时不可达时重试则可能有意义。调用链上每层都各自重试可能放大下游请求量。哪层负责重试、总体等待预算是多少要放在一张时间线上看。没有负载和延迟信息就不要报一个看起来专业的固定次数只要说清如何根据预算和故障类型决定。用户要看到哪一种中间状态失败路径不只存在于服务之间。提交后暂时拿不到最终结果界面是显示处理中、允许查询还是直接报失败如果显示失败却后台继续执行用户再次提交就可能把技术上的不确定性变成重复业务操作。设计里可以把「已接收」「执行中」「完成」「失败」分开但每个状态要对应事实。已接收不等于已经执行成功失败也需要说明还能不能重试。状态的命名并不能替代状态转换的条件。最后沿着故障再走一遍请求超时后怎么找回结果进程重启后怎么恢复重复到达后怎么识别。每经过一个节点指出状态存在哪里、由谁推进、怎样发现长期没有进展。这样画出来的监控需求才有对象而不只是一句「加日志和告警」。面试时间不够时可以少扩展一种组件保留一条完整失败路径。沿它讲清可接受的重复、丢失和延迟比把所有系统名词都摆上去更容易检验设计。你的方案里最难回答的是请求没到还是事情做完了却没人知道