Проектирование архитектуры «товар на складе»

Question

Я изо всех сил пытаюсь разработать приложение для продажи, в котором покупатели могут регистрировать уведомления о пополнении запасов. Это может быть очень просто для небольших приложений, с небольшим количеством пользователей и несколькими различными элементами, однако давайте предположим, что следующий сценарий:

1. приложение имеет около 1+ миллионов пользователей (Amazon, eBay, Ali Express et c)

2. все пользователи хотят купить бананы, но его нет в наличии

3. каждый пользователь создает уведомление о пополнении запасов

4. пополнение запасов бананов

Для каждого пополнения запасов список оповещений о пополнении должен повторяться и отправляться соответствующим образом (электронная почта, pu sh et c).

Как сконструированы такие системы? Какие базы данных, инструменты и т. Д. c?

Answer 1

Системы уведомлений пользователей обычно основаны на очереди. То, какая база данных поддерживает систему управления запасами, не имеет большого значения.

Вам нужны две очереди с потоком, подобным следующему:

1. Обновление инвентаря с 0 к >0 (или к чему бы то ни было пополнение запасов) добавляет элемент в очередь оповещений о пополнении запасов.

2. Работник БД потребляет элементы из очереди оповещений о пополнении запасов, применяет бизнес-логику c и отправляет пользователей в очередь уведомлений.

3. Работник по уведомлению получает пользователей из очереди уведомлений и обрабатывает / отправляет электронные письма, pu sh, sms, et c ...

Преимущества этой конструкции:

• Пересылка в очередь оповещений о пополнении запасов может быть реализована различными способами: A SQL Триггер БД или сохраненный pro c , logi c в процессе загрузки или даже хронографическое задание, которое сканирует БД.

• Отдельный работник оповещения о пополнении сводит к минимуму объем дополнительной работы, которую должен выполнять процесс загрузки БД инвентаря делать. Самое большее, он должен добавлять элементы в очередь.

• Отделение работника оповещения о пополнении запаса от работника уведомлений изолирует бизнес-логику c, которая определяет оповещение о пополнении запаса, позволяя интеграцию с существующая очередь уведомлений.

Недостатки этого дизайна:

• Требуются две очереди и два работника.

Некоторые вопросы, которые следует учитывать

• Насколько важна задержка уведомлений? Люди делают ставки? Нужно ли им знать в эту минуту , что он есть в наличии, или будет достаточно знать сегодня ?
• Должны ли когда-нибудь отправляться уведомления? Сколько оповещений о пополнении запаса установит пользователь? Если кто-то получит два электронных письма в один и тот же день для разных предметов, или это будет раздражать?