Why are notifications and broadcast events queued by default?

Question

Laravel

Hello. I am writing a project, using notifications and broadcast events out of the box. The send method on the notification facade sends the notification to the queue, and only sendNow sends it instantly. It’s the same with broadcast events - everywhere they write about the ShouldBroadcast interface, which sends an event to the queue, and it is it that is used in the framework, and ShouldBroadcastNow has only a description in the documentation in a few lines and that’s it.
At first I used the default options with queues, but later I saw that this adds a significant delay, even considering my --sleep=0.05 for several queue workers. Now I use only sendNow and ShouldBroadcastNow, because I see no reason not to do this.
Question: why is the variant with queues used by default, and why is it tacitly recommended? The only explanation I can see is that such things are sometimes done when processing HTTP requests, but even there I don't see the point in reducing the response time from the server by 10ms in order to increase load and latency. I ask because if I'm missing something, and they do it for a reason, then I should return everything as it was originally with queues.
Thanks in advance.

Answer 1

Sending notifications, like broadcast events, is not part of the response to a client request. Therefore, it is more correct to process them after sending the response to the client.
The use of queues when sending notifications (with the possible exception of notifications stored in the database) is justified, because notifications can be not only for the user, but also for another microservice or product. While sending notifications, the service (SMS gateway, mailer, api Telegram / Slack etc) may be unavailable, which will lead to a timeout. In the event of an error sending asynchronously, the worker will be able to retry, while an error during synchronous sending will also timeout the client, and the notification will not come. has not been preserved anywhere (and asynchronous ones live separately, in the same radish or database), although they are waiting for it.
The same goes for events. The client does not need to wait when you do your business there - give him an answer and send events even in batches.
The question here is not in the manic desire to take away 10 ms of your life from you, but in the principle of division of responsibility.