Вопросы архитектуры уведомлений по электронной почте

Question

Мы стремимся разработать службу уведомлений по электронной почте, в которой электронные письма могут планироваться ежедневно, еженедельно или ежечасно на основе определенных действий, которые происходят в нашей системе (регистрация пользователей), или сводных электронных писем, отправляемых каждую пятницу, например.* Каков наилучший способ убедиться, что дубликаты электронных писем не отправляются?Возможно, мы подумали о том, чтобы приложение записывало запись в очередь всякий раз, когда происходит системное действие, но, похоже, у этого есть еще одна точка отказа.Или, может быть, просто сделав все уведомления управляемыми данными, например, выберите всех пользователей, для которых дата создания больше, чем сейчас.Но с этим сценарием нам нужен способ убедиться, что если служба снова запустится, дубликаты электронных писем не будут отправлены.

любые идеи будут великолепны!

Answer 1

Мои 2 цента

1) Очереди. Очереди отлично подходят для задач, в которых вы хотите использовать архитектуру типа «один вход и один выход». Очереди отделяют системы и позволяют сбалансировать нагрузку системы. Они обычно используются с несколькими рабочими на одном и другом конце. Вы просто добавите (возможно, много) сообщений в очередь, а затем запустите очередь bulk . ИМО - нерациональное использование памяти и ресурсов.

2) Управление данными через пользователей . Гораздо проще реализовать, однако для каждого уведомления вы будете проверять каждого пользователя и сильно нагружать БД.

3) Управление данными через уведомления пользователя . Кроме того, вы можете создать отдельную таблицу UserNotifications, куда каждый пользователь будет добавлен после регистрации. Гораздо проще выбрать нужных пользователей в течение определенного периода времени, и вы не сохраните их в памяти. После отправки уведомления вы удаляете пользователя из таблицы UserNotifications.