📩 Всё про брокеры: как работают и зачем нужны 📩

Брокеры — это посредники в передаче сообщений между системами или сервисами.

Они позволяют асинхронно обмениваться данными и обеспечивают гарантию доставки сообщений.


👉 Принцип работы:

1. Сервис 1 (Producer/ Производитель) хочет отправить данные в Сервис 2 (Consumer/ Потребитель).

2. Сервис 2 в это время может быть перегружен или занят.

3. Чтобы Сервис 1 не ждал, пока Сервис 2 станет доступен, он кладет сообщение в Брокер и продолжает свою работу.

4. Брокер сохраняет сообщение и ставит его в очередь к обработке.

5. Как только Сервис 2 становится доступен, то он забирает сообщение из Брокера и обрабатывает его.

По сути брокеры - это временные Базы Данных,

которые гарантируют, что сообщения (данные) в них будут храниться, пока их не заберут и не обработают соответствующие системы или сервисы.

👉 Брокеры могут использоваться:
+ в сервисной и микросервисной архитектуре,
+ в событийно-ориентированной архитектуре (EDA),
+ когда нужна фоновая обработка событий в монолите,
+ для асинхронных интеграций.


👉 Брокеры сообщений предлагают два основных шаблона обмена данными:

1. Точка-точка (Point-to-Point Messaging)
Это паттерн, используемый в очередях сообщений, где существует один отправитель и один получатель. Каждое сообщение в очереди отправляется только одному получателю и может быть обработано только один раз.

2. Публикация-подписка (Publish/Subscribe Messaging)
В этом паттерне отправитель (producer) публикует сообщения в определённую тему (topic), а подписчики (consumers) подписываются на темы, чтобы получать сообщения.
Все сообщения, опубликованные в теме, доставляются всем приложениям, подписанным на неё.
Применяется в случаях, где несколько систем должны получить одну и ту же информацию.


Возможности и логика работы брокеров отличаются в зависимости от конкретного решения.

Основные решения по брокерам на рынке:
✅ Apache Kafka
✅ RabbitMQ
✅ ActiveMQ
✅ Amazon MQ, Amazon SQS
✅ Яндекс Message Queue (YMQ) - аналог Amazon
✅ и другие.

#АрхитектураGA

🔔 Уже завтра! Бесплатный практикум по Архитектуре для Системных Аналитиков 🔔

Хотите развиваться в теме проектирования архитектуры и работать в IT-продуктах с брокерами и микросервисами? Тогда вам сюда!


🚀 От монолита к микросервисам: пошаговый план с примером
🗓 Доступ с 31 мая до 2 июня [сб - пн]

👉 Узнать подробнее и зарегистрироваться

🎥 Урок в записи — смотрите в удобное время.


Что разберём:
1. Монолит: плюсы и минусы
2. SOA vs MSA: в чём разница и когда что выбрать
3. Пошаговый план деления монолита на микросервисы
4. Разбор кейса по вынесению модуля из монолита в деталях: архитектура, вынесение данных в отдельную БД, особенности
5. Почему молодым продуктам лучше делать модульный монолит
6. Как аналитику расти в сторону архитектура и что для этого нужно


Практика, реальные кейсы и ответы на вопросы.


Регистрируйтесь, получайте опыт и переходите на новый уровень в системном анализе! 🙌

🤔 Всё про Agile, Scrum, Kanban и «Документация не нужна» 🤔

В этом выпуске разбираемся, что такое Agile на самом деле, и как системные аналитики работают в таких командах.

Если вы начинающий системный аналитик или только делаете первые шаги в IT, этот эпизод поможет разобраться, что такое Agile (Scrum, Kanban).

👉 А если вас раздражает фраза “документация не нужна”, вы не понимаете, зачем столько созвонов и почему это всё в Agile — этот выпуск также для вас.


🔗 Сайт эпизода


Слушайте эпизод и расширяйте свою профессиональную экспертизу!


Эпизод доступен в:
⏯ Apple Podcast
⏯ Яндекс.Музыка
⏯ Telegram
⏯ Castbox
⏯ Звук
⏯ Spotify
⏯ RuTube
⏯ YouTube
⏯ VK Video


Участие в сообществе Системных Аналитиков GetAnalyst — это шаг к новому опыту и развитию в карьере каждый день! 💫

Есть такая фраза: "не усложняй".

Это работает и в разработке систем.

Лучшие решения - простые 🙌

И иногда джуны находят эти решения случайно, и лучше, чем опытные специалисты 😀

P.S. Не знаю кто в Hendai сделал эту прекрасную рекламу с котами, но она проста и прекрасна (Оригинал в запретграме) 🐈‍⬛


P.S.S. Доступ к бесплатному обучению по Архитектуре открыт 📚

Я способна отложить абсолютно всё: от похода к врачу до обучения в Гарварде 🙌

Вроде хочешь перемен, а вместо действий — бесконечное «сделаю завтра».

Поход к врачу откладывается до следующего месяца, пробежка вдоль океана — до «когда будет настроение», мечты о новом образовании — на неопределённое «потом» 🙌

А внутри — растущее разочарование и усталость от самой себя.

Так может продолжаться долго.


Мой актуальный рекорд прокрастинации: почти год откладывала обучение и сертификацию Гарварде 🎓

Казалось, ну куда мне — нет времени, а если я тупить буду на английском, бизнес пока маленький… синдром самозванца forever 💗

Но в итоге просто взяла и отправила заявку, пока в очередной раз изучала сайт и раздумывала.
И всё: я в деле, назад дороги нет 🤪🥲

Цель есть. Энергия появилась.
Сейчас готовлюсь, планирую как команды меня подстрахуют, чтобы я могла держать фокус на учёбе.

Получится? Не знаю.
Но я уже в деле и надо будет сдать кучу домашек с жесткими дедлайнами.
У меня появился чёткий план.
И поддерживающее сообщество студентов, кто будет со мной проходить этот путь.



Я уже убедилась: стоит сделать первый шаг — и появляется ощущение лёгкости и силы.

Едва сдвинешься с места — и мир как-будто сам начинает тебе помогать реализовать план 🪄


Так что если ты тоже постоянно откладываешь что-то важное, попробуй сделать маленький шаг уже сегодня.
Просто один шаг навстречу цели.
Ты удивишься, сколько энергии и перемен он может дать 🦄

🎱 8 шагов, чтобы разобраться с Kafka 🎱

1️⃣ Что такое Kafka?
2️⃣ Сообщения в Kafka
3️⃣ Topics & Partitions
4️⃣ Kafka Producer
5️⃣ Kafka Consumer
6️⃣ Kafka Cluster
7️⃣ Сценарии использования Kafka


Подробнее про Kafka в подкасте GetAnalyst
🔗 Kafka: что нужно знать Системному аналитику


Сохраняйте картинку в личный архив.
Это идеальный чек-лист для подготовки к собеседованиям ✅

#АрхитектураGA

⭐️ Kafka - что надо знать для работы Системному аналитику ⭐️

Apache Kafka — это распределённая платформа потоковой обработки данных.

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


Основные компоненты:

✔️ Продюсеры (Producers)

1) Генерируют сообщения/события к обработке и отправляют в топики (темы).

2) Определяют, в какую партицию топика записывать данные: автоматически или по заданным правилам.

3) Могут быть чем угодно: микросервисы, устройства IoT и другие приложения.

4) Поддерживают режимы отправки:
+ Синхронный — ждёт подтверждения от Kafka перед отправкой следующего сообщения.
+ Асинхронный — отправляет сообщения без ожидания ответа.

5) Могут гарантировать доставку с разными уровнями подтверждения (acks):
+ acks=0 — без ожидания подтверждения (возможна потеря данных, высокая скорость).
+ acks=1 — подтверждение только от лидера партиции (среднее).
+ acks=all — подтверждение от всех реплик (максимальная надёжность).


✔️ Потребители (Consumers)

1) Подписываются на один или несколько топиков и получают сообщения/события.

2) Могут работать как отдельные клиенты или объединяться в группы (Consumer Groups) для параллельной обработки сообщений.

3) В группе консьюмеров каждый участник обрабатывает свою часть партиций.

4) Kafka гарантирует, что каждое сообщение будет обработано хотя бы одним потребителем в группе.

5) Модели доставки сообщений:
+ at-least-once — как минимум 1 раз, возможны дубликаты.
+ exactly-once — ровно один раз.


✔️ Топики (Topics) — логическая тема, куда продюсеры отправляют сообщения, а потребители их читают


✔️ Партиции (Partitions) — подмножество данных внутри топика, которое позволяет распределять нагрузку и масштабировать обработку сообщений. Каждый топик состоит из одной или нескольких партиций


✔️ Брокер (Broker) — сервер Kafka, который отвечает за хранение, управление и передачу данных внутри кластера


✔️ Кластер — это группа брокеров, работающих вместе для масштабирования и распределённой обработки данных


#АрхитектураGA

⭐️ Устройство Kafka: топики, партиции, брокеры, кластеры ⭐️


✔️ Топики (Topics)

1) Логическая категория или тема, куда Продюсеры отправляют сообщения, а Потребители их читают.

2) Представляют собой поток сообщений, где каждое имеет: ключ, значение, метаданные.

3) Не удаляют сообщения сразу после обработки — данные хранятся в топике в течение заданного времени.

4) Могут быть разделены на партиции, что позволяет распределять нагрузку между Продюсерами и Консьюмерами.


✔️ Партиции (Partitions)

1) Каждый топик состоит из одной или нескольких партиций (разделов).

2) Сообщения внутри партиции хранятся в строгом порядке (FIFO — "первым пришёл, первым обработался").

3) Разные партиции могут обрабатываться параллельно, что увеличивает производительность Kafka.

4) Каждое сообщение в партиции получает уникальный порядковый номер (offset), который используется Потребителями для чтения данных.

5) Продюсеры могут отправлять сообщения в партиции автоматически или по определённому ключу (например, все заказы одного клиента попадут в одну партицию).

6) Один потребитель из Группы Консьюмеров читает данные только из своей партиции, что позволяет распределять нагрузку.

7) Повышение надежности обеспечивается через репликацию: выделяют Leader Replica (основная копия данных партиции) и Follower Replica (копирует данные лидера в синхронном или асинхронном режиме).


✔️ Брокеры (Brokers)

1) Хранят топики и их партиции.

2) Обрабатывают запросы Продюсеров на запись и Консьюмеров на чтение данных.

3) Управляют репликацией партиций для отказоустойчивости.

4) Автоматически перераспределяют нагрузку при добавлении новых брокеров в кластер.



✔️ Кластер (Cluster)

1) Это группа брокеров, работающих вместе для масштабирования и распределённой обработки данных.

2) Использует ZooKeeper или KRaft для координации (назначает лидеров партиций, отслеживает состояние брокеров).

3) Позволяет добавлять новые брокеры без остановки системы.

4) Поддерживает автоматическое восстановление при сбоях отдельных узлов.


#АрхитектураGA

🧩 Как встроить Kafka в архитектуру, и главное зачем: разбор на примере проекта #GreenChargeGA 🧩

Ранее мы спроектировали схему архитектуры проекта для станций зарядки электро-авто.

Но если в архитектуре не использовать брокер сообщений, а делать прямые синхронные вызовы между микросервисами (через REST/gRPC), могут возникнуть проблемы:

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

➖ Если хотя бы один сервис при обработке сложного запроса не отвечает, перегружен или упал, исходный запрос зависает или падает с ошибкой

➖ Сложность в аналитике и аудите

Чтобы решить их, в архитектуру встраивают брокеры сообщений.



Давайте разберём как это работает на примере:
👉 Сценарий обработки события окончания зарядки



👉 Без брокера

1. Сервис Телеметрии отправляет запрос на API Gateway об окончании зарядки

2. API Gateway проксирует его на Сервис Платежей

3. Сервис Платежей регистрирует кол-во израсходованной энергии, определяет цену и списывает средства с банковской карты, привязанной к ЛК пользователя

4. Сервис Платежей вызывает Сервис Программы Лояльности для начисления бонусных баллов

5. Сервис Платежей вызывает Сервис Уведомлений для отправки уведомления

6. Возврат ответа на Сервис Телеметрии об успешной обработке события завершения зарядки

❌ Проблема:
Если Сервис Программы Лояльности или Сервис Платежей недоступны, то....? Начинаем "городить костыли" в алгоритме с ретраями (повторами) и не только... 🥲



👉 С брокером Kafka

1. Сервис Телеметрии отправляет событие (сообщение) charging.finished в Kafka об окончании зарядки, в топик charging-events. ✅ На этом он выполнил свою миссию по зарядке и более ничего не ждёт.

2. Сервис Платежей подписан на топик charging-events и событие charging.finished в Kafka. Он забирает оттуда это событие, когда готов и не нагружен (хоть сразу, хоть через 3 часа)

3. Сервис Платежей обрабатывает это событие:

3.1. Регистрирует кол-во израсходованной энергии, определяет итоговую цену и списывает средства с карты

3.2. Отправляет событие о списании средств charging.paid в Kafka, топик charging-events
✅ На этом Сервис Платежей выполнил свою миссию и более ничего не ждёт.

4. На событие charging.paid в топике charging-events подписаны Сервисы Программы Лояльности и Уведомлений.
Когда они будут готовы, то тогда и заберут в обработку событие, и каждый обработает его по отдельности.


✅ Преимущества:
Даже если сервисы Платежей, Лояльности или Уведомлений будут недоступны или будут реагировать ошибкой, необработанное событие об окончании зарядки / завершении платежа будет храниться в брокере и ожидать обработки.

Обычно обработка происходит очень быстро, что процесс выглядит как-будто синхронно, но на самом деле это не так. За счёт брокера мы организовали фоновую обработку событий (=задач), когда один сервис не ждёт завершения работы другого.

Брокер - как временная БД, гарантирует, что событие рано или поздно обработают.
А сервисам, которые участвуют в сценарии, не надо рассчитывать на его строго-последовательное и синхронное выполнение.



👉 Итого получаем:
Внедренный механизм асинхронной обработки событий с использованием Kafka сделал систему более устойчивой к сбоям и гибкой для масштабирования.



Если ещё не изучали Kafka, то здесь можно найти самые важные материалы:
🔗 ссылка


#АрхитектураGA

💃 Хореография в микросервисах: разбор примера для #GreenChargeGA 🕺

Хореография — это подход, при котором каждый сервис самостоятельно реагирует на события, происходящие в системе.

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

Координация действий происходит через брокер сообщений: Kafka, RabbitMQ и др.

👉 Важно для понимания!
Брокер это место хранения сообщений, как временная БД, и он ничем не управляет, а только временно хранит события к обработке.


Каждый микросервис:
✅ подписан на определённые события в брокере,
✅ обрабатывает их, когда они появляются,
✅ не знает, какие другие сервисы участвуют в процессе.


👉 Пример 1:
Завершение зарядки электромобиля на станции GreenChargeGA

🟢 После завершения сессии зарядки Сервис Телеметрии публикует событие charging.finished в брокер.


Что происходит дальше:

1. Сервис Платежей получает событие charging.finished, списывает средства с карты пользователя и публикует событие payment.success.

2. Сервис Лояльности слушает событие об успешной оплате payment.success и начисляет бонусы. После чего генерирует событие о добавлении бонусов loyalty.bonusAdded.

3. Сервис Уведомлений слушает события payment.success и loyalty.bonusAdded и отправляет пользователю уведомление с итогами.

Таким образом, за счёт правильно спроектированной событийной модели, мы можем организовать асинхронное выполнение всей цепочки действий — без необходимости задерживать пользователя у зарядной станции.

Все шаги выполняются в фоне, это пример гибкой и масштабируемой архитектуры.



👉 Пример 2
Пользователь завершил настройку профиля

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

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

🟢 Событие profile.setupCompleted — публикуется в брокер от Сервиса Управления Пользователями, когда пользователь завершил заполнение профиля.

Подписанные микросервисы:
🔸 Сервис Уведомлений — отправляет приветственное сообщение с подсказками по началу использования.
🔸 Сервис Лояльности — активирует стартовые бонусы в рамках приветственной кампании.
🔸 Сервис Аналитики — сохраняет событие завершения настройки для последующего анализа поведения новых пользователей.

Все эти действия автономны и могут запускаться независимо, без координации друг с другом. Ни один из них не зависит от результата другого — если, например, уведомление не ушло, это не повлияет на выдачу бонусов или сбор аналитики.



Преимущества хореографии:

💫 Масштабируемость:
Можно легко подключить новые сервисы, которые будут реагировать на события.
Например, маркетинговый сервис, который будет запускать цепочку писем — просто подписав его на profile.setupCompleted.

💫 Устойчивость:
Ошибки одного сервиса не мешают другим.

💫 Параллельность:
Все действия выполняются максимально быстро для пользователя, без задержек на обработку.


Часть схемы архитектуры проекта с хореографией:
🔗 [открыть схему архитектуры C4]

#АрхитектураGA

Я не планировала выкладывать это сейчас… Но не могу удержаться ❤️‍🔥🥰😻

На этой неделе мы завершили мартовский поток по Архитектуре.
И сразу после занятия коллега прислала мне скрин из чата с последней онлайн-встречи, которую она вела.

Сердце взрывается от благодарности — вам, нашим аналитикам, и моим потрясающим коллегам: Екатерине Герасимовой и Екатерине Пантелей, кто помогает мне с ведением онлайн-встреч и поддержанием программы в актуальном состоянии.

Такие слова нельзя просто оставить в архиве 😊

Спасибо!
Что не боитесь идти вглубь.
Что выбираете системность.
Что растёте на наших глазах.

Вы — вдохновляете 💚🦭

#АрхитектураGA #студентыGetAnalyst

🧩 Новый проект на интеграцию: бронирование экскурсий в #TravelGA с оплатой через ВТБ 🧩

Путешествия всегда востребованы — а мы проектируем систему, которая поможет не только найти интересную экскурсию, но и оплатить её онлайн.


🟢 Задача:
В текущих мобильных и веб-приложениях #TravelGA реализован только просмотр экскурсий.
Цель — добавить функциональность бронирования и онлайн-оплаты эксскурсий через платёжную систему ВТБ.


🟢 Сценарии к проектированию:
1. Пользователь выбирает одну или несколько экскурсий и оплачивает бронирование.

2. Пользователь отменяет часть оплаченных экскурсий (или все) и оформляет возврат, если это допустимо по правилам экскурсии.


👉 Что предстоит сделать Системному Аналитику:
1. Выделить ключевые Use Case
2. Провести первичный анализ API-документации ВТБ: наличие нужных методов, рекомендуемый порядок интеграции
3. Определить влияние интеграции на архитектуру системы
4. Протестировать платёжное API ВТБ в Postman, чтобы понять, как он реально работает
5. Описать интеграционные Use Cases: логику работу системы с техническими деталями
6. Сформировать требования для интеграционных REST API-методов
7. Дополнить требования UML-диаграммами
8. Описать маппинги данных и доработки БД

Мы будем последовательно разбирать эти шаги для проекта.


🟢 Результаты
✔️ Полные постановки задач на интеграцию с банком
✔️ Коллекция Postman-запросов для API ВТБ
✔️ Отработанный кейс интеграции от анализа до реализации


Хотите участвовать? Подписывайтесь на GetAnalyst и следите за обновлениями 😉

Добро пожаловать в наш интеграционный проект!

#ИнтеграцииGA #vtbAPI

📚🎧 Интеграции для СА и БА: актуальная подборка материалов 🎧📚

Длинные выходные — редкая возможность совместить отдых и саморазвитие.

Даже если нет времени на видео или статьи, включите подкаст во время прогулки, дороги или тренировки.


Маленький шаг к лучшей версии себя — уже сегодня 😉


Послушать и посмотреть:

🎧 Подкаст "Проблемы в работе с задачами на интеграции"

📹 Postman: навык тестирования REST API за вечер

📹 Опасные интеграции - про альтернативные сценарии и обработку типовых ошибок

🎧 Подкаст "Идемпотентность и коммутативность API: что это и как применяют на практике" - про проблемы дубликатов запросов

🎧 Подкаст "Что такое вебхуки (Webhooks) и зачем они нужны" - оптимизация работы интеграций

📹 Доставить и не потерять: синхронизация данных в распределенных системах - основы очередей сообщений

🎧 Подкаст "Kafka: что нужно знать Системному аналитику" - глубже в понимание очередей и брокеров

🎧 Подкаст "RabbitMQ и его отличия от Kafka: что важно знать системным аналитикам"


Практические руководства по Postman:

📚 Практическое руководство по Postman - тестирование API DaData (с нуля до результатов)

📚 Практическое руководство по Postman - тестирование API ChatGPT

📚 Практическое руководство по Postman - тестирование API Unisender


Шаблоны постановок задач:

💎 Полный интеграционный Use Case - рассылка email через Unisender (с брокерами и микросервисами)

💎 Полный интеграционный Use Case - автоматическое создание задач во внутренней системе ToDoist для сотрудников компании после оплаты заказов

💎 Интеграционный REST API-метод - структурирование адресов через DaData



Ещё больше про интеграции:

🎓 Практический курс Интеграции Систем - работа онлайн с Екатериной Ананьевой и экспертами программы

🎓 Материалы для самообучения по Интеграциям (пакеты вебинаров)



Всё по интеграциям от GetAnalyst вы всегда можете найти в канале по хэштегу #ИнтеграцииGA 🙌


Прекрасных выходных!