设计“商品库存警报”体系结构

Question

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

1. 应用程序大约有1+百万用户(亚马逊、eBay、AliExpress等)
2. 所有用户都想购买香蕉，但它的缺货
3. 每个用户创建一个再库存警告
4. 香蕉是重新进货

对于每一项重新进货，必须对重新储存警报列表进行迭代并相应地发送(电子邮件、推送等)。

这些系统是如何设计的？什么样的数据库、工具等？

Answer 1

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

您需要两个队列，其流如下所示：

1. 库存更新从0到>0 (或任何重新库存)将该项添加到重新库存警报队列中。
2. DB工作者从重新库存警报队列中消费项目，应用业务逻辑，并将用户推送到通知队列中，并呈现/发送电子邮件、推送、短信等.

这种设计的优点：

可以通过多种方式实现推送到重新库存警报队列的

• ：SQL触发器或存储proc、加载进程中的逻辑，甚至扫描DB的chron作业。
• 单独的再库存警报工作人员将库存DB加载过程必须完成的额外工作量降到最低。充其量，它必须向queue.
• Separating添加项--从通知工作者分离出定义重新库存警报的业务逻辑，从而允许与现有通知队列集成。

这种设计的缺点：

• 需要两个队列和两个工作人员。

一些需要考虑的事情

• 通知延迟有多重要？人们在竞购什么东西吗？他们是否需要在这一分钟知道它是库存的，还是知道今天的suffice?
• Should通知会被批处理？用户将设置多少重新储存警报？一个人应该在同一天收到两封不同项目的电子邮件，还是会很烦人？