architecture - 设计一个 "item stock alert"架构

Question

我正在努力构建一个销售应用程序，买家可以在该应用程序上注册商品补货警报。对于只有很少用户和很少不同项目的小型应用程序来说，这可能非常简单，但是让我们假设以下场景:

应用拥有约 1+ 百万用户(Amazon、eBay、AliExpress 等)

所有用户都想买香蕉，但它断货了

每个用户创建一个补货警报

香蕉补货

对于每件商品补货，补货警报列表必须相应地迭代和发送(电子邮件、推送等)。

这样的系统是如何设计的？哪种数据库、工具等？

Answer 1

用户通知系统通常是基于队列的。究竟是什么数据库支持库存管理系统并不那么重要。

您需要两个队列，其流程如下:

库存更新来自 0至 >0 (或任何补货)将项目添加到补货警报队列。

数据库工作人员使用补货警报队列中的项目，应用业务逻辑，并将用户推送到通知队列。

通知 worker 使用来自通知队列的用户并呈现/发送电子邮件、推送、短信等...

这种设计的优点:

推送到补货警报队列可以通过多种方式实现:SQL DB 触发器或存储过程、加载过程中的逻辑，甚至是扫描 DB 的 chron 作业。

一个单独的补货警报工作人员最大限度地减少了库存数据库加载过程必须做的额外工作量。最多，它必须将项目添加到队列中。

将补货警报工作人员与通知工作人员分开可以隔离定义补货警报的业务逻辑，从而允许与现有通知队列集成。

这种设计的缺点:

需要两个队列和两个 worker 。

需要考虑的一些事项

通知延迟有多重要？人们是否在竞标
某物？他们是否需要在这一分钟知道它有货，或者
知道今天就足够了吗？

是否应该批量通知？用户将设置多少个补货提醒？有人应该在同一天收到两封不同项目的电子邮件，还是会很烦人？