前几篇写了功能原型、技术方案、用户调研。现在到了最硬核的部分——组局的业务流程状态机。
一个产品好不好，70% 看设计，30% 看代码。但状态机写错了，产品从第一天起就是错的。
这篇文章我打算讲透：一个组局从”我想打场球”到”打完球各回各家”，中间经历了哪些状态，状态之间怎么跳转，跳转的触发条件是什么，以及 30 多个边角case怎么处理。
一、为什么状态机是这个产品最难的部分社交产品的状态...
上一篇把功能拆清楚了。这一篇说技术——用什么堆出来，怎么部署，成本多少。
如果你不是开发者，可以跳着看，重点看”为什么这么选”和”要花多少钱”。
一、整体技术栈决策这个产品不是高并发、高实时性产品。它的特征：
用户量级：MVP 阶段 1000-5000 活跃用户
并发特征：组局时间集中在下午/晚上/周末，非 7×24 小时
实时需求：低（通知用推送，不需要 WebSoc...
在技术圈里，我们经常看到各种”炫技”式的系统设计建议。有些是LinkedIn优化的”你肯定没听过队列”式的帖子，有些是Twitter优化的”如果你在数据库里存布尔值就是糟糕工程师”的聪明技巧。即使是好的系统设计建议，有时也可能并不实用。
作为一个在2026年仍在一线写代码的工程师，我想分享一些关于优秀系统设计的思考。这些不是什么高深的理论，而是经过实践检验的朴实智慧。
什么是优秀的系统设计？...