Почему по дефолту нотификации и броадкаст эвенты попадают в очередь?
Здравствуйте. Пишу проект, использую нотификации и броадкаст эвенты из коробки. Метод send на фасаде нотификаций отправляет нотификацию в очередь, и только sendNow отправляет ее мгновенно. С броадкаст эвентами тоже самое - везде пишут про интерфейс ShouldBroadcast, который отправляет эвент в очередь, и в фреймворке используется именно он, а ShouldBroadcastNow имеет лишь описание в документации в несколько строчек и на этом все.
Сначала я использовал дефолтные варианты с очередями, но позже увидел, что такие это добавляет существенную задержку, даже учитывая мой --sleep=0.05 для нескольких воркеров очередей. Сейчас же использую только отправку sendNow и ShouldBroadcastNow, ибо не вижу причин не делать этого.
Вопрос: почему по дефолту используется именно вариант с очередями, и негласно рекомендуют именно его? Единственное обьяснение, которое я вижу, это то, что такие вещи иногда делаются при обработке HTTP запросов, но даже там я не вижу смысла сокращать время ответа от сервера на 10мс ради того, что бы увеличить нагрузку и задержки. Спрашиваю, потому что если я что-то упускаю, и так делают не просто так, то мне стоит вернуть все как было изначально с очередями.
Отсылка уведомлений, как и широковещательных событий не является частью ответа на запрос клиента. Поэтому их правильнее обрабатывать после отправки ответа клиенту.
Использование очередей при отправке уведомлений (за исключением, быть может, уведомлений, складываемых в БД) оправдано, т.к. уведомления могут быть не только для пользователя, но и для другого микросервиса или продукта. Во время отправки уведомлений сервис (смс-шлюз, рассыльщик почты, api Telegram/Slack etc) может быть недоступен, что приведет к падению по таймауту. В случае ошибки отправки асинхронно воркер сможет повторить попытку, в то время, как ошибка при синхронной отправке отлупит по таймауту еще и клиента, а уведомление не придет т.к. нигде не сохранилось (а асинхронные живут отдельно, в том же редисе или БД), хотя его и ждут.
То же самое касается событий. Клиенту нет необходимости ждать когда вы там свои дела сделаете - отдайте ему ответ и шлите события хоть пачками.
Вопрос здесь не в маниакальном желании отобрать у вас 10 мс жизни, а в принципе разделения ответственности.
В моей ситуации скорость получения эвента очень важна, а вот ответ на запрос и так пустой в 99% случаев. Нотификашки тоже только броадкастят. Да, в идеале, конечно, запрос не должен был ответственен за это, но думаю что в моем случае такой компромис вполне оправдан.
