Publish-Subscribe

Базовый System Design
≈ 1 мин чтения

Издатель не выбирает одного конкретного получателя

В Publish-Subscribe издатель публикует событие в канал или topic, а каждый заинтересованный подписчик получает собственную возможность его обработать.

                 -> Analytics
OrderCreated ->  -> Email
                 -> Loyalty

Сервис заказов сообщает факт OrderCreated, но ему не нужно знать, сколько потребителей существует и что именно каждый из них сделает с событием.

Это уменьшает прямую связанность

Новый подписчик можно добавить без изменения издателя: например, подключить аудит или аналитику к уже существующему событию. Издатель зависит от контракта события, но не от API каждого потребителя.

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

Подписчики работают независимо

Ошибка одного потребителя не обязана останавливать остальных: аналитика может временно отставать, пока письмо пользователю уже успешно отправлено. Именно поэтому pub/sub хорошо подходит для нескольких независимых реакций на один факт.

Publish-Subscribe — не широковещательный вызов методов. Издатель сообщает событие, а каждый подписчик сам решает, как на него реагировать и нужен ли ему этот поток данных вообще.