В чем разница между шиной и очередью?

Разница между шиной (Bus) и очередью (Queue)

Это два различных архитектурных паттерна для интеграции компонентов в системе. Оба основаны на асинхронном обмене сообщениями, но используют совершенно разные принципы доставки и маршрутизации. На своем опыте видел, как неправильный выбор может привести к проблемам архитектуры.

Очередь (Message Queue)

Принцип работы: Point-to-Point

Producer → Queue → Consumer (ровно один!)

Характеристики:

• FIFO (First In First Out) — сообщения обрабатываются в порядке поступления
• Один потребитель — каждое сообщение забирает ровно один потребитель
• Load Balancing — если много потребителей, они делят сообщения между собой
• Удаление — сообщение удаляется после обработки
• Нет повторной доставки по умолчанию — потребитель должен подтвердить

Реальные примеры очередей:

• RabbitMQ (Queue)
• AWS SQS
• Redis Lists
• Celery (Python Task Queue)

Пример использования: Обработка заказов

Order Service → Queue → Worker 1 (обрабатывает заказ 1)
                    → Worker 2 (обрабатывает заказ 2)
                    → Worker 3 (обрабатывает заказ 3)

Каждый заказ обрабатывает ровно один worker. Если worker упадет — заказ вернется в очередь.

Преимущества Queue:

• Простая логика: один в один
• Автоматическое распределение нагрузки
• Гарантирует обработку каждого сообщения
• Низкие требования к памяти (обработал и удалил)
• Хорошо для массовой обработки

Недостатки Queue:

• Только один потребитель на сообщение
• Не подходит для broadcast
• Сложнее с множественной логикой (несколько действий)

Шина (Message Bus / Event Bus)

Принцип работы: Publish-Subscribe

Publisher → Bus → Subscriber 1
              → Subscriber 2
              → Subscriber 3 (ВСЕ получают!)

Характеристики:

• Topic/Event based — сообщения группируются по типам событий
• Множественные подписчики — все подписанные компоненты получают событие
• Broadcast — одно событие для многих
• История опциональна — некоторые шины хранят события
• Независимость подписчиков — они обрабатываются независимо

Реальные примеры шин:

• Apache Kafka (Topic-based)
• RabbitMQ (Topic/Fanout exchange)
• Google Pub/Sub
• AWS EventBridge
• NATS

Пример использования: Событие регистрации пользователя

Auth Service создает event "user.registered"

Бус распространяет:
  → Email Service (отправляет приветственное письмо)
  → Analytics Service (логирует событие)
  → CRM Service (создает профиль)
  → Welcome Campaign Service (запускает workflow)

Все четыре сервиса получают одно и то же событие и обрабатывают независимо.

Преимущества Bus:

• Множественные потребители одного события
• Слабая связанность (publisher не знает о subscribers)
• Легко добавлять новых subscribers
• Событийная архитектура
• История может быть доступна (replay events)

Недостатки Bus:

• Сложнее гарантировать обработку всех событий
• Может быть больше нагрузка на систему (копии для каждого)
• Нужна более сложная логика обработки ошибок

Сравнительная таблица

Примеры из практики

E-commerce система с очередью:

Checkout Service → Order Queue → Worker Pool
                                    ↓
                            Каждый заказ ровно один раз
                            обрабатывает ровно один worker

E-commerce система с шиной:

Checkout Service отправляет order.created
        ↓
    Event Bus
        ├→ Inventory Service (зарезервировать товар)
        ├→ Payment Service (взять платеж)
        ├→ Notification Service (отправить email)
        ├→ Analytics Service (залогировать событие)
        └→ Warehouse Service (подготовить к отправке)

Все обрабатываются параллельно и независимо

Когда использовать Queue?

Используй очередь когда:

• Нужно обработать задачу один раз
• Важен порядок обработки (FIFO)
• Нужно распределить нагрузку между workers
• Пример: обработка платежей, генерация отчетов, отправка писем

Task Service → Queue → Multiple Workers
(отправил задачу)    (распределяют работу)

Когда использовать Шину?

Используй шину когда:

• Одно событие должно обработать несколько систем
• Системы должны быть слабо связаны
• Нужна история событий (replay)
• Новые подписчики добавляются часто
• Пример: системные события, уведомления, аналитика

Event occurs → Bus → Multiple Subscribers
(что-то произошло)  (каждый реагирует по-своему)

Комбинированный подход

В большинстве современных систем используют оба вместе:

Event Sourcing:
- Шина для основных событий (user.registered, order.created)
- Очереди для обработки задач (send email, generate report)

Пример:
1. User Service создает user.registered event в Kafka
2. Email Service подписана на событие (из bus)
3. Email Service отправляет задачу send_email в Queue
4. Worker из QueuePool обрабатывает email

Выбор технологии

RabbitMQ может быть обоим:

• Queue mode: если использовать одну очередь
• Bus mode: если использовать Topic Exchange и multiple bindings

Kafka естественная шина:

• По дизайну это pub-sub
• Хранит события
• Множественные потребители

SQS естественная очередь:

• By design point-to-point
• Простая модель

Выбор между шиной и очередью — это выбор между broadcast логики (шина) и load balancing логики (очередь). На практике модернизм часто требует оба варианта в одной системе.