在我们的应用程序中，我们目前使用dynamoDb来存储通知详细信息。因此，调度程序每天运行两次，查询"notificationType"(pk -> notifiactionType，sk -> userId(。 在每个项目中都有一个属性(时间戳(，如果时间戳大于当前时间，则基于该属性将发送触发器(对于某些记录，需要在时间戳后一天发送邮件的更多业务逻辑(。现在，一旦用户执行了发送通知的活动，则将删除该条目
我的问题是，如果 notificationType 的数据变大，那么检索所有数据是多余的，因为对于某些记录，通知不会被发送。 因此，使用了更多的读取容量，这可能会在以后的时间点增加成本。 在这种情况下，明智的做法是使用现有的dynamoDb或移动到任何其他数据库，如mongoDb，cassandra或任何其他数据库。
注意：我主要关心的是成本
另一种选择是使用工作流引擎，该引擎可以对每个用户的通知过程进行建模，而不是批处理作业。这样，您可以避免扫描大量数据，因为引擎将依赖持久计时器在适当的时间执行操作。
我在 Uber 领导的开源项目 temporal.io 被多家公司用于类似通知的场景，并经过了 2 亿个开放并行工作流的测试。