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

Зачем нужны брокеры сообщений

• Буферизация: обработка пачками (20–30 записей) вместо по одной; данные попадают в очередь и обрабатываются позже.
• Асинхронность: сервис отправил сообщение и продолжает работу, не ожидая ответа (например, заказ такси — поиск водителя в фоне).
• Слабое связывание: продюсер и консюмер не знают друг о друге, общаются через очередь. Независимое масштабирование и деплой.
• Отказоустойчивость: сообщения сохраняются в очереди при падении консюмера; обработка возобновится после восстановления.

Модели доставки: Push — брокер сам отдаёт сообщения консюмеру (низкая задержка, нужна настройка backpressure); Pull — консюмер запрашивает данные (устойчивость к перегрузке, контроль частоты).

Kafka: основные понятия

• Продюсер — пишет в топик. Консюмер — читает из топика (модель pull).
• Брокер — сервер Kafka в кластере. Топик — логическая очередь (аналог таблицы). Партиция — физическая часть топика (минимум одна).
• Offset — смещение в партиции (сколько записей прочитано). Консюмер сохраняет offset и продолжает с него.
• Data Retention — данные не удаляются после чтения; удаление настраивается (по времени или размеру). Пример: в Яндексе для трекинга — 4 дня.

Роутинг по партициям: по ключу (hash), по правилу или random. Распределение задаётся в коде/SDK. Пример: по ride_id — все события одной поездки в одной партиции.

RabbitMQ: модель

• Exchange — узел маршрутизации (Direct, по ключу, Fanout и др.). Не хранит сообщения.
• Queue — очередь, где лежат сообщения. Консюмер подписывается на очередь.
• Модель Push: брокер отдаёт сообщения консюмеру. После подтверждения (ack) сообщение удаляется из очереди.

Пример: Exchange направляет сообщения об отмене заказа в очередь уведомлений; сервис уведомлений обрабатывает их асинхронно.

Гарантии доставки

• At least once: доставка хотя бы раз; возможны дубликаты. Обработка должна быть идемпотентной или с дедупликацией.
• At most once: не более одного раза; при сбое возможна потеря.
• Exactly once: ровно один раз — через идемпотентность продюсера/консюмера и уникальные ключи сообщений.

Retry — повторная отправка при сбое для достижения at least once. Идемпотентность — повторная обработка того же message_id не меняет результат (например, проверка по ключу перед записью).

Альтернативные способы хранения

Хранение на клиенте

Данные в приложении на устройстве пользователя (толстый клиент, мобильное приложение). Пример: кэш последних поездок в приложении такси. Удобно для офлайна и снижения запросов к серверу; объём и надёжность ограничены устройством.

CDN (Content Delivery Network)

• POP (Point of Presence) — кэш-серверы близко к пользователю.
• Прокси — определяет геолокацию и направляет запрос на ближайший POP или на origin.
• Origin — исходный сервер с контентом.

Модели: Pull — контент кэшируется при первом запросе (экономия трафика); Push — контент заранее заливается на edge (например, премьера на Netflix). Пример: статические карты и ассеты такси кэшируются через CDN для снижения задержки.

Итог: брокеры (Kafka, RabbitMQ) дают асинхронность, масштабируемость и отказоустойчивость через очереди и партиции; CDN и клиентское хранение оптимизируют доступ к контенту и снижают нагрузку на backend.