@denlem
Programmer

Подскажете по архитектуре системы уведомлений?

В рамках веб сайта пишется система уведомлений пользователей по различным каналам (telegram/email/push/sms.. и т д) . Предлагается такой вариант архитектуры. Подскажите пожалуйста слабые стороны

Общая архитектура нотификатора:
  1. На каком-либо этапе создается уведомление(-я) в виде добавления записи(-ей) в БД (сущность NotificationMessage)
  2. CRON раз в 1-5 минут достает из БД все(или часть) уведомлений со статусом "не отправлено"
    и погружает эти уведомления в очередь RabbitMQ
  3. Консюмер достает из очереди уведомления и отправляет их по различным каналам (в зависимости от настроек пользователей, уведомлений и т д) и проставляет статусы "отправлено" в БД всем отправленным сообщениям

Вопросы:
  • На сколько надежна/логична такая схема нотификатора?
  • Какой возможен программный потолок количества отправляемых уведомлений в единицу времени, при такой архитектуре на одном сервере?
  • Вопрос задан
  • 252 просмотра
Решения вопроса 1
mayton2019
@mayton2019
Bigdata Engineer
При данной схеме тебе база и крон вообще не нужны. Пиши сразу в Rabbit. Если consumer обладает логикой неуспеха обработки - то пускай кидает необработанное вообщение в специальную мусорку (Dead-Letter-Quee) для анализа ошибок впоследствии.

Какой возможен программный потолок количества отправляемых уведомлений в единицу времени, при такой архитектуре на одном сервере?

На этот вопрос невозможно ответить. Цифры могут отличаться в разы в зависимости от выбранного железа. Но современные MQ настолько быстрые что с большей вероятностью твой софт не сможет их загрузить событями.
Узким местом в такой системе будет скорее всего твой софт.
Ответ написан
Пригласить эксперта
Ваш ответ на вопрос

Войдите, чтобы написать ответ

Войти через центр авторизации
Похожие вопросы