GetAnalyst - Навыки • Системный анализ • Бизнес-анализ

📚👩‍💻 Доступ к бесплатному обучению по Архитектуре открыт 👩‍💻📚

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

💎 Хореография и оркестрация микросервисов: практика проектирования процессов

🗓 Доступ до 2 декабря [вт]
🕘 ~4 часа, смотрете в удобное время

🔗 Зарегистрироваться


👉 План:
1. Основы архитектуры: монолит и микросервисы
2. Разработка схемы архитектуры
3. Оркестрация процессов: практика
4. Введение в брокеры сообщений (RabbitMQ, Kafka)
5. Хореография процессов: практика


👉 Это не типичный демо-урок, а полноформатное практическое обучение, после которого вы получите реальные инструменты и знания для работы.

Планируйте слот в календаре и смотрите его, пока доступ открыт 🙌

-----
Этот открытый урок - вводное занятие к практической программе Проектирование архитектуры для системных аналитиков
-----

Вопрос? Пишите @getanalyst или info@getanalyst.ru 🤝

🚀 8 шагов, чтобы разобраться с брокером Kafka 🚀

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


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


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

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

🔥 7 вопросов с подвохом по Архитектуре: хореография микросервисов + понимание брокеров в EDA 🔥


1️⃣ Когда хореография микросервисов хуже оркестрации?

✔️ Сложные линейные бизнес-процессы с кучей условий (сложный онбординг, платежные цепочки, обращения тех поддержки и др)

✔️ Надо явно видеть шаги процесса и управлять им

✔️ Когда важны SLA и время на выполнение шагов

В таких случаях удобнее, когда:
+ есть компонент, который явно хранит состояние процесса
+ видно “шаги” и переходы по ним
С этим помогает оркестрация.



2️⃣ Сервис записал данные в свою БД, но упал до публикации события. Что произойдёт в хореографии и как это чинить?

Многие говорят «ретраи к брокеру» (повторные запросы) и всё. Но это лишь часть ответа.

Ситуация:
Обработка данных на микросервисе прошла, но событие в брокер не опубликовано → остальные сервисы никогда не узнают об изменении.

Решение:
Transactional Outbox / Outbox pattern:
В одной транзакции к БД с бизнес-данными пишем запись в специальную outbox-таблицу.

Отдельный воркер (фоновый процесс) читает из outbox и публикует событие в брокер, с ретраями.

Также иногда используют Change Data Capture (CDC) по БД - отслеживание изменений.



3️⃣ Как в хореографии реализовать шаг, который зависит сразу от двух событий из разных сервисов?
Например: бонус начисляем только если есть "пользователь зарегистрирован" и "оплачен первый заказ"?

Нужен агрегатор/process manager (отдельный сервис/Kafka Streams и др), который:
+ хранит состояние двух параметров: userId - , orderId
+ пришло первое событие — пометили “жду второе”
+ пришло второе — выполняем действие (начисляем бонус)

Это уже кусочек оркестрации, спрятанный внутри одного сервиса.

Также нужно учесть что делать, если второе событие не пришло.



4️⃣ Как в хореографии реализовать таймаут шага?
Например, оплата должна пройти за 15 минут, иначе заказ отменяем.

Используется process manager / timeout-сервис / scheduler:

1. При старте процесса публикуется событие "оплата началась"

2. Параллельно где-то создаётся “таймер” на 15 минут (например, Cron)

3. Если за 15 минут не пришло событие "Платеж успешен" / "Ошибка оплаты":
+ таймер генерирует событие "Ошибка таймаута по платежу",
+ другие сервисы реагируют: отменяют заказ, снимают резерв и т.п.

Важно понять: управление интервалами времени в работе процесса не решается «само по себе» брокером — нужен компонент, который хранит состояние ожидания.


5️⃣ Биллинг слушает событие "Заказ оплачен" и должен списать деньги ровно один раз. Любое сообщение может прийти дважды. Как вы гарантируете отсутствие двойного списания?

Ошибочный ответ:
«брокер гарантирует доставку ровно один раз»

Реализуем проверки на уровне потребителя события:
+ идемпотентность операций: бизнес-ключ (orderId + paymentId)
+ уникальность в БД на этот ключ
+ таблица processed_messages с messageId и состоянием.


6️⃣ Можно ли построить систему только на хореографии, без оркестрации?

В теории — можно, но:
+ всё равно появятся сервисы-агрегаторы / процесс-менеджеры / scheduler’ы, которые управляют процессами
+ как только один сервис начинает хранить состояние процесса и ждать другие события, он выполняет роль локального оркестратора.

Более правильный ответ: в реальных системах почти всегда смесь подходов хореографии и оркестрации.


7️⃣ Вы добавляете новый микросервис в существующую хореографию процессов. Как сделать так, чтобы он не поломал остальных, когда начнёт слушать существующие события?

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

Важно:
+ не добавлять обязательные поля в существующие события (сообщения), которые отправляем в брокер
+ не менять JSON (формат сообщений) уже используемых событий
+ если нужно другое поведение — вводить новые типы событий, а не менять старые.


А какие ещё вопросы по брокерам и хореографии вы встречали на собеседованиях на СА? Делитесь в комментариях ✍️


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

🕺Хореография микросервисов - детальный разбор с примером 💃

👉 Хореография — это архитектурный шаблон взаимодействия микросервисов, в котором бизнес-процессы реализуются как цепочка независимых реакций на события.


Каждый сервис знает только:
▫️ какие события он слушает,
▫️ что делает при их получении,
▫️ какие события публикует дальше.


👉 Интеграция сервисов в таком подходе в основном асинхронная, через брокер сообщений (Kafka, RabbitMQ) / event bus.


👉 Пример хореографии
Оформления заказа с привязанной карты в сервисе доставки еды


🟡 Запуск хореографии:
Пользователь нажимает "Оформить заказ" в web-приложении:

1. Приложение отправляет запрос на API Gateway

2. API Gateway проверяет авторизацию и маршрутизирует заказ в Сервис Заказов

3. Сервис Заказов:
+ обновляет статус заказа в БД на "Ожидает оплаты"
+ публикует событие в Брокер Kafka - "Заказ подтверждён"
❗️ Деньги с пользователя не списаны

4. Сервис Заказов возвращает ответ на API Gateway.

5. API Gateway возвращает ответ с инфо о заказе на web-приложение, где показываем пользователю сообщение "Заказ принят"❌


🟡 Асинхронная работа - хореография:
Запускается параллельный поток событий. Frontend и пользователь могут идти по своим делам.

1. Сервис Платежи (далее - С) читает событие "Ожидает оплаты" из Kafka и запускает логику списания денег с карты пользователя.

2. Платежи публикует событие "Платеж упешен" в Kafka.


Параллельно:
----
3А. С Уведомлений читает событие "Платеж упешен" из Kafka и отправляет push+sms пользователю❌

3C. С Заказов читает событие "Платеж упешен" из Kafka и меняет его статус в своей БД на "Оплачен"❌

3B. Рестораны читает событие "Платеж упешен" и проверяет:
+ кухня не перегружена?
+ доступность блюд?
+ время работы и т.п.

4. Если ок, то С Рестораны публикует событие "Заказ подтверждён".
----

Параллельно:
4А. С Уведомлений читает "Заказ подтверждён"..❌
4C. С Заказы читает "Заказ подтверждён"..❌
4B. С Курьеры читает "Заказ подтверждён"..


Далее на картинке к посту 🖼

❌ - конец процесса

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

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

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

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


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

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

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

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

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

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

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

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

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


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

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

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


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

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

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

✅ Очередь vs Брокер: вопросы к собеседованиям с подвохом ❓

Очередь сообщений — это структура данных,
которая хранит сообщения до тех пор, пока их не заберёт получатель.

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


Вопросы с подвохом, которые вы можете встретить на собеседованиях для Middle+ Системного аналитика:

👉 1. Если у нас есть очередь сообщений, зачем нужен брокер?

👉 2. Может ли очередь работать без брокера?

👉 3. Могу ли я использовать брокер без очередей сообщений?

👉 4. Если я использую очередь сообщений, могу ли я гарантировать доставку сообщения?

👉 5. Очередь всегда работает по принципу FIFO (первое пришло - первое вышло из очереди)?

👉 6. Может ли очередь работать с несколькими производителями и потребителями?


Подробная статья:
🔗 Брокер и очередь сообщений: что это и в чем отличия?


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

🔵 С4 - нотация моделирования для схем архитектуры 🔵

Можешь показать схему архитектуры системы в виде прямоугольников и стрелочек? Отлично!

Но если в отрасли есть стандарты, лучше использовать их.

Предлагаю познакомиться с нотацией моделирования архитектуры C4 👇


C4 помогает представлять архитектуру системы в виде 4-х уровней:

👉 Контекст (C4/Context)
Система, её интеграции и пользователи.
✔️ Главный прямоугольник - наша система
✔️ Серые прямоугольники - внешние
✔️ Пользователи

👩‍💻 Полезна бизнес- и техническим специалистам


👉 Контейнер (C4/Container)
Независимые по коду приложения в системе, детализация главного прямоугольника c C4 / Context.
✔️ Пользователи и внешние системы с уровня C4 / Context
✔️ Мобильные, веб- и десктоп приложения
✔️ Сервер-приложения: монолит, сервисы, микросервисы, API Gateway
✔️ Базы данных и файловые хранилища
✔️ Виды API
✔️ Технологии (языки программирования, СУБД, протоколы для API и др)
✔️ Базы данных и файловые хранилища
✔️ Очереди и брокеры
Схему удобнее использовать в адаптированном виде, когда на этом уровне не показывают сервисы и микросервисы, а переносят их на уровень глубже - C4 / Component. Иначе она очень перегружена.

👩‍💻 Полезна архитекторам, разработчикам и системным аналитикам.


👉 Компонент (C4/Component)
Модули кода и зависимости между ними.
Детализирует один из контейнеров с C4 / Container.
На каждый контейнер своя схема.
Отлично подходит для детализации модульного монолита.


👉 Код (C4/Code)
На этом уровне детализируют каждый компонент c C4/ Component, показывая его реализацию в коде. Обычно это UML-диаграмма классов или другая визуализация.


Материалы:
🔗 Официальный сайт C4
🔗 Пример архитектуры C4 в Miro
🔗 Нотация С4 — примеры диаграмм и инструменты

Основные инструменты:
🔗 Draw.io
🔗 Structurizr

Примеры схем:
🔗 RideFlow - заказ такси
🔗 TelMed - телемедицина
🔗 BookingGA - аренда недвижимости (МСА с брокерами)
🔗 GreenChargeGA - зарядки для электроавто (МСА с брокерами)


Элементы нотации с пояснениями в картинках к посту 🙌

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

📌 [29.11 - 02.12] Хореография и оркестрация микросервисов: продвинутый практикум для СА и БА 🗓

Приглашаем вас на открытый урок по погружению в архитектуру систем:


💎 Хореография и оркестрация микросервисов
🗓 29 ноября - 2 декабря [сб-вт]
🕘 Время на обучение: ~4 часа

🔗 Зарегистрироваться

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


Ваши результаты:
✅ Разберётесь в принципах хореографии и оркестрации на практике.
✅ Научитесь описывать процессы в микросервисной архитектуре.
✅ Поймёте, как использовать брокеры сообщений Kafka/RabbitMQ для интеграций микросервисов.
✅ Сможете уверенно обсуждать архитектурные решения с архитекторами и разработчиками.
✅ Подготовитесь к вопросам на интервью уровня Middle+ / Senior.


Этот практикум - полноформатное обучение.
Он даст вам реальные инструменты и знания, которые помогут не просто пробить стеклянный потолок, а значительно поднимут планку вашей карьеры.


-----

Это вводное занятие к практической программе Проектирование архитектуры для системных аналитиков, которая стартует в декабре:
🟢 12 онлайн-встреч
🟢 50 часов теории в записи
👉 Есть проверка ДЗ у всех участников, в разных форматах

🎄 Новогодние каникулы учтены
😔 С 2026 года повышение цен
🎁 Бонусы и лучшие цены в последний раз до 26.11

-----


Хотите учиться на реальных задачах?
Регистрируйтесь и пробуйте уже в эти выходные! 😉

🎻 Оркестрация микросервисов: полный практический гайд + материалы 📚

Оркестрация – это подход, при котором специальный сервис-оркестратор управляет группой микросервисов (МС).

👉 Оркестратор:
1. знает какие сервисы вызвать по API (обычно REST / gRPC)
2. в каком порядке
3. работает с условиями, сложными алгоритмами
4. если что-то пойдёт не так, то он "откатит" операцию на всех МС, которые уже были вызваны

Так сложный процесс превращается в цепочку задач. А Оркестратор следит за их выполнением.


👉 Как работает оркестратор
на примере Интернет-магазина:

1. Покупатель оформляет заказ через Web-приложение

2. Web-приложение отправляет запрос в API Gateway

POST ...

/orders

3. API Gateway маршрутизирует запрос на Оркестратор

4. Оркестратор присваивает id новой операции и вызывает API сервиса заказов

5. Сервис Заказов создает новый заказ в БД.
Результат - в Оркестратор

6. Оркестратор вызывает сервис Склада, чтобы зарезервировать товар

7. Склад подтверждает резерв или сообщает об отсутствии товара.
Результат - в Оркестратор

8. Оркестратор вызывает сервис Доставка для оформления отправления

9. Сервис доставки рассчитывает маршрут и время доставки, оформляет доставку.
Результат - в Оркестратор

10. Оркестратор вызывает сервис Уведомлений для отправки email/SMS о подтверждении заказа и доставке

11. Сервис Уведомлений выполняет отправку.
Результат - в Оркестратор

12. Оркестратор отправляет итоговый ответ в API Gateway, откуда он возвращается в Web-приложение


🔹Оркестратор вызывает API сервисов и ждёт ответ.
🔹Он может сохранять состояние процесса, чтобы возобновить его при сбое.
🔹 Если что-то идёт не так, оркестратор выполнит компенсации - откатит выполненные шаги.


📦 Готовые решения для оркестрации:
▫️ Camunda – BPM-движок с поддержкой диаграмм процессов (BPMN)
▫️ OpenBPM - аналог Camunda в России


📚 Подборка материалов:
🎧 Camunda и BPMN в микросервисах для процессов техподдержки
📝 Оркестрация и API Gateway – разбор реального примера
🎧 Внедряем Camunda: обзор и моделирование BPMN


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

🎻 Оркестрация + Хореография: пример схемы интеграции микросервисов 💃

-------

🎻 Оркестрация - это подход, при котором в системе на Backend есть централизованный компонент - оркестратор, который управляет выполнением бизнес-процесса:

▫️ знает последовательность шагов,
▫️ вызывает нужные микросервисы в нужном порядке,
▫️ анализирует ответы,
▫️ принимает решение, что делать дальше (успех / ошибка /альтернативный сценарий).

Вся логика процесса сосредоточена в одном месте.

👉 Оркестратор - отдельный сервис на Backend.

Для его реализации часто используют BPM-платформы вроде Camunda или пишут самописное решение.

-------

💃 Хореография - это подход, при котором нет центрального управляющего компонента для процесса.

Вместо этого:

▫️ система строится вокруг событий, например:
++ OrderCreated - заказ создан,
++ PaymentSucceeded - платеж успешен,
++ UserProfileCreated - пользователь зарегистрирован
▫️ микросервисы:
++ публикуют события,
++ подписываются на события, которые им интересны
▫️ поведение каждого сервиса описывается шагами: «пришло событие X → выполнить действие Y → опубликовать событие Z»

👉 В центре архитектуры с хореографией обычно стоит брокер сообщений на Backend, вв который микросервисы публикуют события и из которого их читают.

Условно его можно представить как “журнал событий”, чем-то похожий на временную БД для сообщений.

Для хореографии в сложных и высоконагруженных системах чаще всего используют Kafka, а также, например, RabbitMQ или другие брокеры.

-------

На картинке к посту наглядно показаны отличия между оркестрацией и хореографией на примере процесса регистрации пользователя ▶️


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

Обратная связь — это не «приятный бонус», а базовый инструмент команды 🛠

Без неё мы быстро начинаем додумывать, обижаться и выгорать.


Причём важны оба направления:
👉 уметь получать обратную связь (и не обижаться на плохое)
👉 и уметь давать её коллегам — своевременно, по делу и с уважением


Почему это критично?

1️⃣ Для мотивации
Наш мозг устроен так, что негатив мы запоминаем лучше.

❗️ Если хорошую работу воспринимать «по умолчанию», а проговаривать только ошибки, человек начинает жить в ощущении, что он всё время «недостаточно хорош».

Регулярное «смотри, вот это у тебя получилось круто» даёт подтверждение смысла и напрямую влияет на желание продолжать стараться.

2️⃣ Для личного роста
Без обратной связи мы видим себя только со своей стороны.

«Я стараюсь» ≠ «Я даю тот результат, который нужен команде».

Конструктивный разбор помогает понять, где именно ты сильный, а где нужен другой подход, навыки, поддержка. Это экономит годы блужданий с мыслями «что со мной не так» (синдромом самозванца🥲)

3️⃣ Для атмосферы в команде
Когда у вас принято говорить вслух хорошее, а не только, когда что-то пошло не так, уровень доверия и открытости совсем другой.


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

🩷

Чем чаще мы подсвечиваем друг другу сильные стороны, тем проще переживаются сложные разговоры.

Если человек регулярно слышит: «ты классно делаешь ...», то одно аккуратное «давай тут поправим» не ломает самооценку, а воспринимается как рабочий процесс.


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

✔️ договориться в команде, что позитивная обратная связь - это не «сюсюканье», а нормальная рабочая практика

И да, чем больше мы искренне говорим друг другу, какие мы классные и в чём, тем меньше шансов, что хороший специалист в какой-то момент тихо уйдёт, так и не услышав: «ты делаешь огромную работу» 💙



P.S. А вам, коллеги, спасибо за обратную связь на обучении, занятиях, в ЛС, и вообще везде! Читаю, вдохновляюсь, радуюсь и бесконечно ценю 🤗