如何保障DynamoDB到Websocket链路中单个条目事件的顺序性？

方案1：绕过EventBridge Pipe，用Lambda+FIFO SQS实现有序流转 #

• 关掉原有EventBridge Pipe，给DynamoDB Stream添加Lambda触发器
• Lambda处理流事件时，将application与feature拼接成{application}#{feature}作为消息分组键，把事件推送到FIFO SQS队列（记得开启队列内容去重，避免重复消息）
• Rails的Action Cable服务消费该FIFO队列——FIFO队列会保证同分组键的消息严格按顺序处理，单个功能开关的更新自然不会乱序

注意：Lambda并发数要和DynamoDB Stream分片数匹配，避免消息堆积；FIFO队列吞吐量有限，若功能开关更新频率极高，需提前评估容量。

方案2：在Rails服务端加一层排序校验 #

• 保留原有标准SNS+SQS架构，无需调整AWS端配置
• 在Rails服务中用Redis或内存缓存，为每个application+feature组合存储最新版本号：可直接使用DynamoDB Stream事件里的SequenceNumber（同一条目更新的SequenceNumber是递增的），或者在DynamoDB表中新增自增version字段
• 消费SQS消息时，先对比消息版本号与缓存中的最新版本：若消息版本更高，就处理并推送，同时更新缓存；若版本更低，直接丢弃这条旧消息

注意：要给缓存设置合理过期时间，避免长期占用内存；服务重启时，需先从DynamoDB拉取所有功能开关的最新版本初始化缓存。

方案3：用Kinesis Data Streams替代SNS+SQS #

• 将DynamoDB Stream的数据转发到Kinesis Data Streams（可用Lambda做中转，或直接配置DynamoDB到Kinesis的流转发）
• 创建Kinesis流时，用application#feature作为分区键——Kinesis会保证同一分区内的消息严格有序
• Rails服务通过Kinesis客户端拉取对应分区的消息，处理后通过Action Cable推送给前端

注意：Kinesis的分区数量决定并发处理能力，需根据更新频率合理规划；拉取消息时要做好checkpoint管理，避免重复处理。

内容的提问来源于stack exchange，提问作者Ryan Pierce Williams