📨 Брокеры сообщений и базы данных

База данных — это склад: ты приходишь и смотришь, что лежит. Брокер — это почта: письма идут получателям, и склад не нужен, чтобы передать новость

Сравнение

Как это работает

1. Сервис заказов записывает заказ в свою базу
2. Он же отправляет событие «заказ создан» в брокер
3. Сервис уведомлений, склад и аналитика читают событие каждый сам, в своём темпе
4. Если склад упал на час, события дождутся его в брокере, и ничего не потеряется
5. Сервис заказов об этом даже не знает, он не ждал ответа

Это и есть асинхронность: отправитель не ждёт получателя. Для менеджера это значит две вещи. Плюс: сервисы и команды меньше зависят друг от друга. Минус: нет мгновенной согласованности, данные в аналитике отстают на секунды или минуты, и с этим нужно работать в требованиях

Kafka и RabbitMQ

Kafka — журнал событий: сообщения хранятся по времени, их можно перечитать, подходит для больших потоков и аналитики. RabbitMQ — классическая очередь: сообщение доставлено и удалено, подходит для задач вроде «отправь письмо». Если команда спорит, что выбрать, это нормальный технический спор, и менеджеру достаточно понимать разницу на этом уровне

Пример из жизни

Интернет-магазин вызывал службу доставки напрямую при каждом заказе. Когда у доставки шли работы, заказы не оформлялись. Команда поставила брокер: заказ сохраняется и событие уходит в очередь, доставка забирает его, когда готова. Клиенты перестали видеть ошибки, а менеджер добавил в требования: статус доставки появляется в кабинете с задержкой до минуты

Важно запомнить

• База — состояние, брокер — события
• Асинхронность снимает зависимость сервисов, но даёт задержку данных
• Kafka — журнал, RabbitMQ — очередь, глубже на собесе менеджера обычно не спрашивают

Как ответить на собесе

Связанные темы