类Jira看板视图应用是否需要使用FIFO SQS规避并发操作问题

问题1：并发移动同一张卡片是否天然不会出现数据损坏？ #

• 结论：该结论不成立
• 原因：Postgres默认使用读提交（READ COMMITTED）隔离级别，普通的SELECT查询不会对查询到的行加锁。如果两个用户同时发起同一张卡片的移动请求，两个事务会先后/同时查询到卡片相同的当前所属阶段，后续各自执行移除原阶段、添加到目标阶段的操作时，会出现丢失更新问题：要么最终卡片同时归属两个阶段，要么后提交的事务直接覆盖先提交的修改结果，完全不符合业务预期。
• 补充：只有你给查询操作加了行级排他锁（比如用SELECT ... FOR UPDATE），或者加了乐观锁控制（比如带版本号校验的更新条件），才能避免这个问题。

问题2：SQS FIFO + Lambda 按顺序处理是否是合理方案？ #

• 这个方案是合理可行的
• 实现要点：你需要把卡片ID作为SQS FIFO队列的消息分组ID（Message Group ID），这样同一个卡片的所有移动请求会被严格按发送顺序消费，Lambda不会并发处理同一张卡片的修改请求，从根源上规避了并发冲突。
• 注意点：该方案会引入额外的链路延迟，正常情况下延迟在几十到几百毫秒区间，对于看板类应用的卡片移动场景，这个延迟用户基本感知不到，属于可接受范围。

问题3：该场景下使用SQS的其他理由/不适用于场景？ #

适合使用SQS的额外理由： #

• 削峰填谷：如果出现短时间大量卡片移动请求（比如团队批量迭代调整、活动峰值），SQS可以把请求暂存下来，Lambda根据处理速度弹性扩缩容，不会直接把数据库流量打满，保护核心存储的稳定性。
• 自动失败重试：如果移动卡片过程中出现数据库临时不可用、网络抖动等异常，SQS内置的重试机制会自动重新投递消息，你不需要自己开发重试逻辑；还可以配置死信队列，把多次处理失败的消息单独存储，方便后续排查问题。
• 业务解耦：你的ECS服务只需要把移动请求发往SQS就可以快速响应前端，不需要同步等待数据库操作完成，能提升前端交互的流畅度；后续如果要新增移动卡片后的关联逻辑（比如操作留痕、给成员发变更通知、统计数据更新），只需要新增消费端即可，不需要修改核心移动接口的代码。

不适合使用SQS的场景： #

如果你的业务对卡片移动的延迟要求极高（要求毫秒级响应），或者已经在数据库层通过乐观锁/悲观锁完成了可靠的并发控制，引入SQS反而会增加架构复杂度，这种场景下就没有必要使用SQS。

内容的提问来源于stack exchange，提问作者feiiiiii