Event Sourcing架构下用fallback队列如何保障客户端一致读承诺

可行的优化方向如下，全部满足不阻塞主预订流程的核心要求：

• 新增低延迟临时KV存储（比如Redis），主流程写入DynamoDB失败时，同步将首个事件写入临时KV（key为预订编码，失效时间设为fallback队列最大重试时长的2倍，避免垃圾数据残留），再写入fallback队列后直接返回成功
• 调整读请求处理逻辑：先走DynamoDB一致读查询，查到直接返回；查不到则去临时KV中查询，存在则直接返回KV中的事件；都不存在才返回错误响应
• fallback队列消费者成功将事件写入DynamoDB后，异步删除临时KV中的对应记录即可
• 优势：全程不增加主流程耗时（KV写入通常在1ms以内），读路径完全符合一致读承诺，业务侧无感知

• 主流程中无论DynamoDB写入成功或失败，都先给预订编码打一个全局临时存在标记（可以存在分布式KV或者单独的DynamoDB标记表，写入成本极低），标记失效时间同队列最大重试时长
• 调整读请求返回规则：如果存在对应预订的临时标记、但DynamoDB未查到事件，返回自定义的临时处理中状态码，要求客户端在100~300ms后重试
• 可将重试逻辑封装到服务内部的SDK/网关层，上层业务客户端完全不需要感知重试逻辑，拿到的结果永远是一致的
• 优势：改造工作量极小，不需要额外存储全量事件，仅需要存标记位，存储成本极低

• 对fallback队列中的事件做优先级分类：首次创建预订的首个事件标记为最高优先级，其余追加事件为普通优先级
• 消费端单独设置高优消费线程池，优先处理高优事件，将队列待处理的时间窗口从通常的数百ms压缩到50ms以内
• 可配合上述透明重试方案使用，重试仅需要1次即可拿到数据，业务侧几乎感知不到延迟

• 主流程返回创建成功响应时，将首个事件的完整数据一并返回给客户端
• 客户端本地缓存该事件，有效期设置为1s，1s内发起的同预订编码查询请求优先读本地缓存，到期后再走服务端查询
• 优势：服务端几乎不需要改造，仅需要调整返回参数和客户端逻辑，适合内部服务调用的场景，对外提供公开API的场景不适用

内容的提问来源于stack exchange，提问作者Mr.J4mes