Проектирование архитектуры «товар на складе» - PullRequest
Новая
       24

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

1 голос
/ 04 мая 2020

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

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

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

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

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

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

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

1 Ответ

1 голос
/ 05 мая 2020

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

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

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

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

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

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

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

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

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

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

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

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

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