Ответ 1
В общем, шина сообщений (например, RabbitMQ, но не ограничиваясь ими) позволяет обеспечить надежную очередь обработки заданий.
Что это означает для вас с точки зрения веб-приложения - это возможность масштабировать ваше приложение по мере роста спроса и поддерживать быстрый и отзывчивый интерфейс.
Вместо того, чтобы заставить пользователя ждать, пока задание будет обработано, они могут запросить обрабатываемое задание (например, нажав кнопку на веб-странице, чтобы начать транскодирование видеофайла на вашем сервере), который отправляет сообщение на ваш автобус, позвольте серверной службе забрать его, когда он включится в очередь, и, возможно, сообщит пользователю, что работа/начнется. Затем вы можете вернуть управление пользовательскому интерфейсу, чтобы пользователь мог продолжить работу с приложением.
В этой ситуации ваш веб-интерфейс делает нулевой тяжелый подъем, вместо этого просто дает пользователю видимость на этапах процесса по вашему усмотрению (например, задание может постепенно обновлять записи базы данных с состоянием процесса, которое вы можете запросить и показ вашему пользователю).
Я бы предположил, что любое веб-приложение, которое испытывает какой-либо значительный трафик, будет иметь такой тип инфраструктуры. Хотя есть недостатки (сетевые сбои могут потенциально нарушить доставку сообщений, более сложную инфраструктуру и т.д.), Преимущества масштабирования вашего бэкэнда становятся все более очевидными. Если вы используете облачные сервисы, этот тип инфраструктуры делает тривиальным добавлять дополнительных обработчиков сообщений для обработки ваших заданий, подписываясь на очередь заданий и просто отбирать сообщения для обработки.