ПРО АНАЛИТИКА | СИСТЕМНЫЙ АНАЛИТИК | АЛЕКСАНДР НЕЗДЕМИНА
Образование · 27 мая 2026 г.
Что реально нужно знать аналитику про брокеры сообщений? — 27 мая 2026 г. в 07:35:38.979
Что реально нужно знать аналитику про брокеры сообщений? Заметил такую штуку, что как только аналитику предстоит сделать интеграцию через брокер, будь-то Kafka, RabbitMQ или какая-то другая очередь, и у него нет опыта в этом, то он начинает теряться: что указать, что должен продумать, как СА, что должна делать команда. У меня даже были кейсы, когда разрабы жаловались на моего аналитика, что он что-то не указал. Поэтому сегодня хочу поделиться своим видением, что реально должен знать аналитик, а что нужно делегировать на разрабов и специально обученных ребят, которые шатают брокеры. ➖➖➖ Чтобы поставить задачу на разработку реально надо знать и описать 4 основных вещи: 1️⃣ Кто мы: получатель или потребитель. И в какую очередь (топик) мы кладем или забираем данные. Какой именно брокер использовать мы сами не выбираем. Это продумываем с разработчиками и архитекторами. 2️⃣ Какие данные и как мы их передаём. Что за событие произошло? Какие поля мы передаем в сообщении? Что обязательно, что опционально? Какой формат данных, например, JSON, XML, Protobuf? Фактически вы описываете тут: ✔️ Структуру сообщения так же, как описываете тело POST-запроса; ✔️ Типы данных и ограничения. 3️⃣ Как мы получаем данные? Здесь нужно зафиксировать: получатель читает сообщения сам (pull) или брокер ему пушит? Как часто? Пачками или по одному? На практике это влияет на проектирование обработчика на стороне получателя. Лучше продумать это самостоятельно, чтобы разрбаотчик не выдумал своего 😁 4️⃣ Что делать с ошибками? Часто, аналитики, которые делают постановку про этот шаг забывают и именно на этом споткнулась моя коллега на которую пожаловались. Тут нам надо описать отклонения от успешного сценария: ✔️ Что если сообщение пришло, но обработка упала? ✔️ Сколько раз система должна попробовать повторно? ✔️ Что происходит с сообщением после N неудачных попыток, потому что надо понимать куда отправлять его, например, в dead letter queue, в лог, в алерт на почту? По факту, это все, что нам нужно помнить. Ну и про идемпотентность, конечно. Я вот здесь про нее писал. На этом всё. Остальное, это уже особенности технологий и как реализовывать - уже совместная работа с командой, потому что под капотом у брокера может быть что угодно: репликации, смещения, политики хранения. Это не ваша зона ответственности. Ваша главная задача - чётко описать контракт на данные и логику обработки ошибок. Кстати, в курсе, в пятом модуле, который появился, начиная с прошлого потока, вы как раз изучаете теорию и на практике делаете постановки на listener и producer. ➡️ УСПЕВАЙТЕ. ОСТАЛОСЬ 14 МЕСТ