Обратная связь — это не «приятный бонус», а базовый инструмент команды 🛠
Без неё мы быстро начинаем додумывать, обижаться и выгорать.
Причём важны оба направления:
👉 уметь получать обратную связь (и не обижаться на плохое)
👉 и уметь давать её коллегам — своевременно, по делу и с уважением
Почему это критично?
1️⃣ Для мотивации
Наш мозг устроен так, что негатив мы запоминаем лучше.
Регулярное «смотри, вот это у тебя получилось круто» даёт подтверждение смысла и напрямую влияет на желание продолжать стараться.
2️⃣ Для личного роста
Без обратной связи мы видим себя только со своей стороны.
Конструктивный разбор помогает понять, где именно ты сильный, а где нужен другой подход, навыки, поддержка. Это экономит годы блужданий с мыслями «что со мной не так» (синдромом самозванца🥲)
3️⃣ Для атмосферы в команде
Когда у вас принято говорить вслух хорошее, а не только, когда что-то пошло не так, уровень доверия и открытости совсем другой.
Важно помнить:
Если человек регулярно слышит: «ты классно делаешь ...», то одно аккуратное «давай тут поправим» не ломает самооценку, а воспринимается как рабочий процесс.
Что можно сделать уже завтра:
✔️ сказать коллеге, за что вы цените его работу
✔️ попросить у близкого коллеги честную обратную связь по своей работе
И да, чем больше мы искренне говорим друг другу, какие мы классные и в чём, тем меньше шансов, что хороший специалист в какой-то момент тихо уйдёт, так и не услышав: «ты делаешь огромную работу» 💙
P.S. А вам, коллеги, спасибо за обратную связь на обучении, занятиях, в ЛС, и вообще везде! Читаю, вдохновляюсь, радуюсь и бесконечно ценю 🤗
Без неё мы быстро начинаем додумывать, обижаться и выгорать.
Причём важны оба направления:
👉 уметь получать обратную связь (и не обижаться на плохое)
👉 и уметь давать её коллегам — своевременно, по делу и с уважением
Почему это критично?
1️⃣ Для мотивации
Наш мозг устроен так, что негатив мы запоминаем лучше.
❗️ Если хорошую работу воспринимать «по умолчанию», а проговаривать только ошибки, человек начинает жить в ощущении, что он всё время «недостаточно хорош».
Регулярное «смотри, вот это у тебя получилось круто» даёт подтверждение смысла и напрямую влияет на желание продолжать стараться.
2️⃣ Для личного роста
Без обратной связи мы видим себя только со своей стороны.
«Я стараюсь» ≠ «Я даю тот результат, который нужен команде».
Конструктивный разбор помогает понять, где именно ты сильный, а где нужен другой подход, навыки, поддержка. Это экономит годы блужданий с мыслями «что со мной не так» (синдромом самозванца🥲)
3️⃣ Для атмосферы в команде
Когда у вас принято говорить вслух хорошее, а не только, когда что-то пошло не так, уровень доверия и открытости совсем другой.
Важно помнить:
🩷
Чем чаще мы подсвечиваем друг другу сильные стороны, тем проще переживаются сложные разговоры.
Если человек регулярно слышит: «ты классно делаешь ...», то одно аккуратное «давай тут поправим» не ломает самооценку, а воспринимается как рабочий процесс.
Что можно сделать уже завтра:
✔️ сказать коллеге, за что вы цените его работу
✔️ попросить у близкого коллеги честную обратную связь по своей работе
✔️ договориться в команде, что позитивная обратная связь - это не «сюсюканье», а нормальная рабочая практика
И да, чем больше мы искренне говорим друг другу, какие мы классные и в чём, тем меньше шансов, что хороший специалист в какой-то момент тихо уйдёт, так и не услышав: «ты делаешь огромную работу» 💙
P.S. А вам, коллеги, спасибо за обратную связь на обучении, занятиях, в ЛС, и вообще везде! Читаю, вдохновляюсь, радуюсь и бесконечно ценю 🤗
💯20❤14🔥5
GetAnalyst_Хореография_и_Оркестрация_Регистрация_пользователя.png
995.1 KB
🎻 Оркестрация + Хореография: пример схемы интеграции микросервисов 💃
-------
🎻 Оркестрация - это подход, при котором в системе на Backend есть централизованный компонент - оркестратор, который управляет выполнением бизнес-процесса:
▫️ знает последовательность шагов,
▫️ вызывает нужные микросервисы в нужном порядке,
▫️ анализирует ответы,
▫️ принимает решение, что делать дальше (успех / ошибка /альтернативный сценарий).
Вся логика процесса сосредоточена в одном месте.
👉 Оркестратор - отдельный сервис на Backend.
Для его реализации часто используют BPM-платформы вроде Camunda или пишут самописное решение.
-------
💃 Хореография - это подход, при котором нет центрального управляющего компонента для процесса.
Вместо этого:
▫️ система строится вокруг событий, например:
++ OrderCreated - заказ создан,
++ PaymentSucceeded - платеж успешен,
++ UserProfileCreated - пользователь зарегистрирован
▫️ микросервисы:
++ публикуют события,
++ подписываются на события, которые им интересны
▫️ поведение каждого сервиса описывается шагами: «пришло событие X → выполнить действие Y → опубликовать событие Z»
👉 В центре архитектуры с хореографией обычно стоит брокер сообщений на Backend, вв который микросервисы публикуют события и из которого их читают.
Условно его можно представить как “журнал событий”, чем-то похожий на временную БД для сообщений.
Для хореографии в сложных и высоконагруженных системах чаще всего используют Kafka, а также, например, RabbitMQ или другие брокеры.
-------
На картинке к посту наглядно показаны отличия между оркестрацией и хореографией на примере процесса регистрации пользователя ▶️
#АрхитектураGA
-------
🎻 Оркестрация - это подход, при котором в системе на Backend есть централизованный компонент - оркестратор, который управляет выполнением бизнес-процесса:
▫️ знает последовательность шагов,
▫️ вызывает нужные микросервисы в нужном порядке,
▫️ анализирует ответы,
▫️ принимает решение, что делать дальше (успех / ошибка /альтернативный сценарий).
Вся логика процесса сосредоточена в одном месте.
👉 Оркестратор - отдельный сервис на Backend.
Для его реализации часто используют BPM-платформы вроде Camunda или пишут самописное решение.
-------
💃 Хореография - это подход, при котором нет центрального управляющего компонента для процесса.
Вместо этого:
▫️ система строится вокруг событий, например:
++ OrderCreated - заказ создан,
++ PaymentSucceeded - платеж успешен,
++ UserProfileCreated - пользователь зарегистрирован
▫️ микросервисы:
++ публикуют события,
++ подписываются на события, которые им интересны
▫️ поведение каждого сервиса описывается шагами: «пришло событие X → выполнить действие Y → опубликовать событие Z»
👉 В центре архитектуры с хореографией обычно стоит брокер сообщений на Backend, вв который микросервисы публикуют события и из которого их читают.
Условно его можно представить как “журнал событий”, чем-то похожий на временную БД для сообщений.
Для хореографии в сложных и высоконагруженных системах чаще всего используют Kafka, а также, например, RabbitMQ или другие брокеры.
-------
На картинке к посту наглядно показаны отличия между оркестрацией и хореографией на примере процесса регистрации пользователя ▶️
#АрхитектураGA
🔥19❤🔥4👍4
🎻 Оркестрация микросервисов: полный практический гайд + материалы 📚
Оркестрация – это подход, при котором специальный сервис-оркестратор управляет группой микросервисов (МС).
👉 Оркестратор:
1. знает какие сервисы вызвать по API (обычно REST / gRPC)
2. в каком порядке
3. работает с условиями, сложными алгоритмами
4. если что-то пойдёт не так, то он "откатит" операцию на всех МС, которые уже были вызваны
Так сложный процесс превращается в цепочку задач. А Оркестратор следит за их выполнением.
👉 Как работает оркестратор
на примере Интернет-магазина:
1. Покупатель оформляет заказ через Web-приложение
2. Web-приложение отправляет запрос в API Gateway
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
Оркестрация – это подход, при котором специальный сервис-оркестратор управляет группой микросервисов (МС).
👉 Оркестратор:
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
❤15👍8🔥8🤔1
Приглашаем вас на открытый урок по погружению в архитектуру систем:
🕘 Время на обучение: ~4 часа
Урок в записи, смотрете в удобное время.
Ваши результаты:
✅ Разберётесь в принципах хореографии и оркестрации на практике.
✅ Научитесь описывать процессы в микросервисной архитектуре.
✅ Поймёте, как использовать брокеры сообщений Kafka/RabbitMQ для интеграций микросервисов.
✅ Сможете уверенно обсуждать архитектурные решения с архитекторами и разработчиками.
✅ Подготовитесь к вопросам на интервью уровня Middle+ / Senior.
Этот практикум - полноформатное обучение.
Он даст вам реальные инструменты и знания, которые помогут не просто пробить стеклянный потолок, а значительно поднимут планку вашей карьеры.
-----
Это вводное занятие к практической программе Проектирование архитектуры для системных аналитиков, которая стартует в декабре:
🟢 12 онлайн-встреч
🟢 50 часов теории в записи
👉 Есть проверка ДЗ у всех участников, в разных форматах
😔 С 2026 года повышение цен
🎁 Бонусы и лучшие цены в последний раз до 26.11
-----
Хотите учиться на реальных задачах?
Регистрируйтесь и пробуйте уже в эти выходные! 😉
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥9❤4🤩2🥰1
🔵 С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
Можешь показать схему архитектуры системы в виде прямоугольников и стрелочек? Отлично!
Но если в отрасли есть стандарты, лучше использовать их.
Предлагаю познакомиться с нотацией моделирования архитектуры 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-диаграмма классов или другая визуализация.
Материалы:
Основные инструменты:
Примеры схем:
Элементы нотации с пояснениями в картинках к посту 🙌
#АрхитектураGA
Please open Telegram to view this post
VIEW IN TELEGRAM
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥24❤6👍5
Очередь сообщений — это структура данных,
которая хранит сообщения до тех пор, пока их не заберёт получатель.
Брокер сообщений — это программное обеспечение,
которое управляет обменом сообщений между приложениями.
Он может включать в себя множество очередей сообщений и дополнительно поддерживать топики, маршрутизацию, обработку и механизмы гарантии доставки.
Вопросы с подвохом, которые вы можете встретить на собеседованиях для Middle+ Системного аналитика:
👉 1. Если у нас есть очередь сообщений, зачем нужен брокер?
👉 2. Может ли очередь работать без брокера?
👉 3. Могу ли я использовать брокер без очередей сообщений?
👉 4. Если я использую очередь сообщений, могу ли я гарантировать доставку сообщения?
👉 5. Очередь всегда работает по принципу FIFO (первое пришло - первое вышло из очереди)?
👉 6. Может ли очередь работать с несколькими производителями и потребителями?
Подробная статья:
#АрхитектураGA
Please open Telegram to view this post
VIEW IN TELEGRAM
Please open Telegram to view this post
VIEW IN TELEGRAM
❤22👍7❤🔥1
Брокеры — это посредники в передаче сообщений между системами или сервисами.
Они позволяют асинхронно обмениваться данными и обеспечивают гарантию доставки сообщений.
👉 Принцип работы:
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
Please open Telegram to view this post
VIEW IN TELEGRAM
❤18👍9🔥6❤🔥1👌1
🕺Хореография микросервисов - детальный разбор с примером 💃
👉 Хореография — это архитектурный шаблон взаимодействия микросервисов, в котором бизнес-процессы реализуются как цепочка независимых реакций на события.
Каждый сервис знает только:
▫️ какие события он слушает,
▫️ что делает при их получении,
▫️ какие события публикует дальше.
👉 Интеграция сервисов в таком подходе в основном асинхронная, через брокер сообщений (Kafka, RabbitMQ) / event bus.
👉 Пример хореографии
Оформления заказа с привязанной карты в сервисе доставки еды
🟡 Запуск хореографии:
Пользователь нажимает "Оформить заказ" в web-приложении:
1. П
2.
3.
+ обновляет статус заказа в БД на "Ожидает оплаты"
+ публикует событие в
❗️ Деньги с пользователя не списаны
4.
5.
🟡 Асинхронная работа - хореография:
Запускается параллельный поток событий. Frontend и пользователь могут идти по своим делам.
1.
2.
Параллельно:
----
3А. С Уведомлений читает событие "Платеж упешен" из
3C. С Заказов читает событие "Платеж упешен" из
3B. Рестораны читает событие "Платеж упешен" и проверяет:
+ кухня не перегружена?
+ доступность блюд?
+ время работы и т.п.
4. Если ок, то С Рестораны публикует событие "Заказ подтверждён".
----
Параллельно:
4А. С Уведомлений читает "Заказ подтверждён"..❌
4C. С Заказы читает "Заказ подтверждён"..❌
4B. С Курьеры читает "Заказ подтверждён"..
Далее на картинке к посту 🖼
#АрхитектураGA #FoodDeliveryGA
👉 Хореография — это архитектурный шаблон взаимодействия микросервисов, в котором бизнес-процессы реализуются как цепочка независимых реакций на события.
Каждый сервис знает только:
▫️ какие события он слушает,
▫️ что делает при их получении,
▫️ какие события публикует дальше.
👉 Интеграция сервисов в таком подходе в основном асинхронная, через брокер сообщений (Kafka, RabbitMQ) / event bus.
👉 Пример хореографии
Оформления заказа с привязанной карты в сервисе доставки еды
🟡 Запуск хореографии:
Пользователь нажимает "Оформить заказ" в web-приложении:
1. П
риложение отправляет запрос на API Gateway2.
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
❤20❤🔥7🔥3
1️⃣ Когда хореография микросервисов хуже оркестрации?
✔️ Надо явно видеть шаги процесса и управлять им
✔️ Когда важны SLA и время на выполнение шагов
В таких случаях удобнее, когда:
+ есть компонент, который явно хранит состояние процесса
+ видно “шаги” и переходы по ним
С этим помогает оркестрация.
2️⃣ Сервис записал данные в свою БД, но упал до публикации события. Что произойдёт в хореографии и как это чинить?
Ситуация:
Обработка данных на микросервисе прошла, но событие в брокер не опубликовано → остальные сервисы никогда не узнают об изменении.
Решение:
Transactional Outbox / Outbox pattern:
В одной транзакции к БД с бизнес-данными пишем запись в специальную outbox-таблицу.
Отдельный воркер (фоновый процесс) читает из outbox и публикует событие в брокер, с ретраями.
Также иногда используют Change Data Capture (CDC) по БД - отслеживание изменений.
3️⃣ Как в хореографии реализовать шаг, который зависит сразу от двух событий из разных сервисов?
+ хранит состояние двух параметров: userId - , orderId
+ пришло первое событие — пометили “жду второе”
+ пришло второе — выполняем действие (начисляем бонус)
Это уже кусочек оркестрации, спрятанный внутри одного сервиса.
Также нужно учесть что делать, если второе событие не пришло.
4️⃣ Как в хореографии реализовать таймаут шага?
Например, оплата должна пройти за 15 минут, иначе заказ отменяем.
1. При старте процесса публикуется событие "оплата началась"
2. Параллельно где-то создаётся “таймер” на 15 минут (например, Cron)
3. Если за 15 минут не пришло событие "Платеж успешен" / "Ошибка оплаты":
+ таймер генерирует событие "Ошибка таймаута по платежу",
+ другие сервисы реагируют: отменяют заказ, снимают резерв и т.п.
Важно понять: управление интервалами времени в работе процесса не решается «само по себе» брокером — нужен компонент, который хранит состояние ожидания.
5️⃣ Биллинг слушает событие "Заказ оплачен" и должен списать деньги ровно один раз. Любое сообщение может прийти дважды. Как вы гарантируете отсутствие двойного списания?
«брокер гарантирует доставку ровно один раз»
Реализуем проверки на уровне потребителя события:
+ идемпотентность операций: бизнес-ключ (orderId + paymentId)
+ уникальность в БД на этот ключ
+ таблица processed_messages с messageId и состоянием.
6️⃣ Можно ли построить систему только на хореографии, без оркестрации?
+ всё равно появятся сервисы-агрегаторы / процесс-менеджеры / scheduler’ы, которые управляют процессами
+ как только один сервис начинает хранить состояние процесса и ждать другие события, он выполняет роль локального оркестратора.
Более правильный ответ: в реальных системах почти всегда смесь подходов хореографии и оркестрации.
7️⃣ Вы добавляете новый микросервис в существующую хореографию процессов. Как сделать так, чтобы он не поломал остальных, когда начнёт слушать существующие события?
+ слушает существующие события без изменения процесса их работы
+ никакие его действия не должны влиять на текущие цепочки по процессам
Важно:
+ не добавлять обязательные поля в существующие события (сообщения), которые отправляем в брокер
+ не менять JSON (формат сообщений) уже используемых событий
+ если нужно другое поведение — вводить новые типы событий, а не менять старые.
А какие ещё вопросы по брокерам и хореографии вы встречали на собеседованиях на СА? Делитесь в комментариях ✍️
#АрхитектураGA
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥31❤6❤🔥2👍2🤩1
GetAnalyst_Kafka_8_шагов_чтобы_разобраться.png
522.6 KB
1️⃣ Что такое Kafka?
2️⃣ Сообщения в Kafka
3️⃣ Topics & Partitions
4️⃣ Kafka Producer
5️⃣ Kafka Consumer
6️⃣ Kafka Cluster
7️⃣ Сценарии использования Kafka
Сохраняйте схему в личный архив.
Это идеальный чек-лист для подготовки к собеседованиям ✅
#АрхитектураGA
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥24❤🔥7👍4❤3👎1
📚👩💻 Доступ к бесплатному обучению по Архитектуре открыт 👩💻 📚
Всем, кто уже зарегистрировался, письмо с доступом пришло на почту сегодня утром.
💎 Хореография и оркестрация микросервисов: практика проектирования процессов
🗓 Доступ до 2 декабря [вт]
🕘 ~4 часа, смотрете в удобное время
🔗 Зарегистрироваться
👉 План:
1. Основы архитектуры: монолит и микросервисы
2. Разработка схемы архитектуры
3. Оркестрация процессов: практика
4. Введение в брокеры сообщений (RabbitMQ, Kafka)
5. Хореография процессов: практика
👉 Это не типичный демо-урок, а полноформатное практическое обучение, после которого вы получите реальные инструменты и знания для работы.
Планируйте слот в календаре и смотрите его, пока доступ открыт 🙌
-----
Этот открытый урок - вводное занятие к практической программе Проектирование архитектуры для системных аналитиков
-----
Вопрос? Пишите @getanalyst или [email protected] 🤝
Всем, кто уже зарегистрировался, письмо с доступом пришло на почту сегодня утром.
💎 Хореография и оркестрация микросервисов: практика проектирования процессов
🕘 ~4 часа, смотрете в удобное время
👉 План:
1. Основы архитектуры: монолит и микросервисы
2. Разработка схемы архитектуры
3. Оркестрация процессов: практика
4. Введение в брокеры сообщений (RabbitMQ, Kafka)
5. Хореография процессов: практика
👉 Это не типичный демо-урок, а полноформатное практическое обучение, после которого вы получите реальные инструменты и знания для работы.
Планируйте слот в календаре и смотрите его, пока доступ открыт 🙌
-----
Этот открытый урок - вводное занятие к практической программе Проектирование архитектуры для системных аналитиков
-----
Вопрос? Пишите @getanalyst или [email protected] 🤝
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥16❤7