01 · 问题
通常各自独立的三种产品被放进了同一个应用：门票销售、付费内容和多商家市集。三者都涉及资金，而且各自对“钱何时算转移”有不同规则——门票先付款、活动时核销，内容解锁一次永久有效，订单要等货到才结算。在同一个账户下，三者还要读起来像一条历史。
作品 04 / 08
Tokowibu — 动漫、Cosplay 与游戏社区超级应用
动漫与 Cosplay 社区超级应用的后端工作：活动售票、付费创作者内容，以及多商家市集。
- 类型
- PT Qomunal Media Pratama
- 阶段
- 已上线
- 技术栈
- Laravel · GraphQL · PostgreSQL
案例分析
问题，以及我的解决方式。
02 · 方法
这里重要的不是功能数量，而是后端必须守住的边界。商家库存和门票配额是有限资源，两个买家可能在同一秒争抢，这种争抢必须在数据库里解决——应用层可能同时运行多个进程，在那里做的检查看不到其他进程。资金还要求可追溯的历史：事后总会被问到的，不是现在是什么状态，而是状态何时、依据什么改变。