Мы умеем быть разными: мягкими, сильными, умными, красивыми — и гораздо глубже, чем просто внешность.
Мы держим в голове десятки задач, замечаем детали, собираем хаос в логику. И часто держим на себе больше, чем о нас принято думать. Не только в работе, но и в жизни.
С 8 марта, дорогие девушки!
Пусть весна и любовь согревают вас, а ваше сияние — всё вокруг 🌸💐🩷☀️
Пусть вас ценят по-настоящему — и в работе, и в жизни! 💙
Мы держим в голове десятки задач, замечаем детали, собираем хаос в логику. И часто держим на себе больше, чем о нас принято думать. Не только в работе, но и в жизни.
С 8 марта, дорогие девушки!
Пусть весна и любовь согревают вас, а ваше сияние — всё вокруг 🌸💐🩷☀️
Пусть вас ценят по-настоящему — и в работе, и в жизни! 💙
2❤77❤🔥19🎉9🍾4
📌 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
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
🔥28❤9👍1
👉 Сегодня последний день заявок по сниженным ценам и доп. обучением по REST 🎁
Сейчас аналитиков всё чаще спрашивают понимание архитектуры.
Не “что такое Kafka”, а:
• где нужен брокер, а где синхронный API;
• что будет при таймауте и дублях сообщений;
• как обеспечиваем целостность и согласованность данных между сервисами;
• в каком случае выбрать gRPC, а где лучше подойдёт REST API.
На программе «Проектирование архитектуры» в GetAnalyst мы уже помогли 250+ аналитикам получить практический опыт работы со сложными сервисными и микросервисными системами.
Благодаря этому они выросли внутри своих компаний, сменили работу и даже перешли в карьерный трек Solutions Architect 😍
Приглашаем и вас получить самые актуальные навыки по архитектуре для СА в новом потоке:
📌 Проектирование архитектуры
📅 Старт 17 марта 2026
🎁 По заявкам до 10 марта 23:59 Мск
лучшие цены и доступ к пакету практикумов по REST API в подарок.
👉 Кому актуально
Опытным системным аналитикам (Middle и выше), кто уже работал с интеграциями и хочет:
+ вырасти в Senior внутри компании,
+ перейти в более сложные продуктовые/платформенные проекты.
👉 По итогам
+ Освоите монолит, SOA, микросервисы - MSA, EDA
+ Получите опыт в проектировании архитектуры с нуля
+ Познакомитесь с GraphQL, gRPC, WebSocket, SSE
+ Научитесь работать с брокерами RabbitMQ / Kafka
+ Получите опыт в нотации C4 для архитектуры
+ Сможете уверенно обсуждать архитектурные решения на интервью и в проектах
📌 Бесплатный вводный практикум
👉 Хореография, брокеры и API Gateway
📅 12 марта (чт), 19:00 Мск
Вопросы? Пишите @getanalyst или info@getanalyst.ru. Поможем оценить текущий уровень и дадим рекомендации по дальнейшим шагам в карьерном развитии 🙌
Please open Telegram to view this post
VIEW IN TELEGRAM
👍8❤1
1. Что такое RabbitMQ и зачем он нужен
2. Как работает RabbitMQ
3. Очереди, обменники (exchange), routing и binding key - ключевая терминология и внутреннее устройство брокера
4. Типы обменников: direct, fanout, topic, headers
5. Пошаговый разбор примера использования RabbitMQ в микросервисной архитектуре
Подробно разбирали брокер в подкасте:
🎧 RabbitMQ и его отличия от Kafka: что важно знать системным аналитикам
Сохраняйте в закладки и делитесь с коллегами
#АрхитектураGA
Please open Telegram to view this post
VIEW IN TELEGRAM
Please open Telegram to view this post
VIEW IN TELEGRAM
👍19❤8🔥8
🟢 [Завтра в 19:00 Мск] Практика по архитектуре для аналитиков: хореография, брокеры и API Gateway 🟢
Уже завтра мы сделаем ваш вечер интереснее, а короткую неделю — продуктивнее обычной! 🙂
Погрузимся в тему, которая помогает системному аналитику брать более сложные интеграционные задачи и делать уверенный шаг к работе в микросервисных командах.
Разберём на практике:
▫️ асинхронные интеграции микросервисов,
▫️ зону ответственности API Gateway в системе,
▫️ брокеры сообщений,
▫️ паттерн "хореографии" в микросервисной архитектуре.
Приглашаем вас на открытый онлайн-практикум:
💎 Хореография, брокеры и API Gateway: как строить процессы в распределенных системах
🗓 12 марта (чт), 19:00 Мск
🟢 Онлайн
👩💻 Спикер: Екатерина Ананьева
🔗 Зарегистрироваться
За один вечер:
✔️ Поймёте роль API Gateway в архитектуре.
✔️ Разберётесь в принципах хореографии процессов на практике.
✔️ Научитесь описывать процессы в микросервисной архитектуре.
✔️ Поймёте, как использовать брокеры для асинхронных интеграций микросервисов.
✔️ Сможете уверенно обсуждать архитектурные решения с архитекторами и разработчиками.
Практикум особенно полезен тем, кто хочет расти до Middle+ / Senior СА или двигаться в сторону Solutions Architect.
Хотите разбираться в архитектуре не в теории, а на практике?
Приходите на эфир завтра, в 19:00 Мск 🔥
Уже завтра мы сделаем ваш вечер интереснее, а короткую неделю — продуктивнее обычной! 🙂
Погрузимся в тему, которая помогает системному аналитику брать более сложные интеграционные задачи и делать уверенный шаг к работе в микросервисных командах.
Разберём на практике:
▫️ асинхронные интеграции микросервисов,
▫️ зону ответственности API Gateway в системе,
▫️ брокеры сообщений,
▫️ паттерн "хореографии" в микросервисной архитектуре.
Приглашаем вас на открытый онлайн-практикум:
🟢 Онлайн
👩💻 Спикер: Екатерина Ананьева
За один вечер:
✔️ Поймёте роль API Gateway в архитектуре.
✔️ Разберётесь в принципах хореографии процессов на практике.
✔️ Научитесь описывать процессы в микросервисной архитектуре.
✔️ Поймёте, как использовать брокеры для асинхронных интеграций микросервисов.
✔️ Сможете уверенно обсуждать архитектурные решения с архитекторами и разработчиками.
Практикум особенно полезен тем, кто хочет расти до Middle+ / Senior СА или двигаться в сторону Solutions Architect.
Хотите разбираться в архитектуре не в теории, а на практике?
Приходите на эфир завтра, в 19:00 Мск 🔥
Please open Telegram to view this post
VIEW IN TELEGRAM
❤11🔥1
RabbitMQ - исследование через CloudAMQP.pdf
5.9 MB
Один из самых удобных способов “потрогать” RabbitMQ руками, не поднимая инфраструктуру у себя - использовать облачный сервис CloudAMQP.
В нём можно в режиме онлайн:
+ развернуть собственный брокер RabbitMQ,
+ посмотреть его настройки,
+ поменять параметры,
+ поэкспериментировать с обменниками и очередями,
+ отправлять сообщения в брокер и тут же их получать.
Подготовила для вас практический гайд по исследованию RabbitMQ через CloudAMQP, в котором вы пошагово сможете:
1. зарегистрироваться в инструменте;
2. создать свой виртуальный сервер с брокером RabbitMQ;
3. настроить exchange и привязанные к нему очереди;
4. задать bindings и routing keys;
5. протестировать отправку сообщений и чтение их из очередей, без необходимости писать код.
Это пошаговое руководство с картинками 🤩
Идеально, если вы только начинаете знакомство с брокерами сообщений, хотите сделать первые уверенные шаги и понять, в какую сторону двигаться дальше.
Скачивайте, сохраняйте гайд и пробуйте инструмент на практике 🤝
P.S. Доступ к CloudAMQP из России может требовать использование VPN.
#АрхитектураGA
Please open Telegram to view this post
VIEW IN TELEGRAM
❤23🔥10👍4
🟢 Встречаемся в 19:00 Мск, онлайн 🟢
Практикум по архитектуре для аналитиков:
👉 Хореография, брокеры и API Gateway: как строить процессы в распределенных системах
🔗 Зарегистрироваться
План:
✔️ Глубокое погружение в микросервисы
✔️ Много каверзных вопросов
✔️ Самая важная теория
✔️ Практика
📚 Дополнительные материалы
Обещаю супер-детальную обратную связь и реальный проектный опыт, который будет полезен в работе и для собеседований!
До встречи! 🙌
Практикум по архитектуре для аналитиков:
👉 Хореография, брокеры и API Gateway: как строить процессы в распределенных системах
План:
✔️ Глубокое погружение в микросервисы
✔️ Много каверзных вопросов
✔️ Самая важная теория
✔️ Практика
📚 Дополнительные материалы
Обещаю супер-детальную обратную связь и реальный проектный опыт, который будет полезен в работе и для собеседований!
До встречи! 🙌
Please open Telegram to view this post
VIEW IN TELEGRAM
❤17🔥8🎉2👍1
❗️Коллеги уже через 3 часа❗️
👩💻 Практический вебинар с Екатериной Ананьевой
💎 Хореография, брокеры и API Gateway: как строить процессы в распределенных системах
⏰ 19:00 Мск
🟢 Онлайн
Ссылку на эфир пришлем в канал за 15 минут до начала.
👩💻 Практический вебинар с Екатериной Ананьевой
⏰ 19:00 Мск
🟢 Онлайн
Ссылку на эфир пришлем в канал за 15 минут до начала.
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥8
🔥🤩 Мощнейшая практика по архитектуре в @getanalysts! 😍❤️
(P.S. доступ уже открыт - до 17.03)
Коллеги, это абсолютный восторг!
Я была безумно рада провести для вас этот прямой эфир!
Комментарии в картинках к посту ❤️🔥
И честно, такие практики получаются по-настоящему мощными и душевными
👉 не только потому, что я подготовила материал, а потому что это делаете вы.
▫️ Ваши вопросы
▫️ Ваша внимательность к деталям
▫️ Ваше желание разобраться и докопаться до сути, а не пройтись по верхам
▫️ Ваша вовлечённость
Я задала основу, но именно вы сделали этот эфир таким живым, глубоким и действительно полезным.
И вот за это вам огромное спасибо!
👉 Я в очередной раз убеждаюсь, что в GetAnalyst собрались действительно очень сильные специалисты.
Что успели:
🔹 Монолит, SOA, MSA и EDA архитектуры на примерах
🔹 API Gateway — ключевые функции и типичные ошибки в понимании
🔹 Kafka и RabbitMQ — архитектура и когда что выбирать
🔹 Работа с Saga-хореография на практике
И почти по каждому пункту успели погрузиться в детали.
📌 Доступ к записи
Для тех, кому не удалось подключиться, остаться до конца или хочется ещё раз пройти всю практику и закрепить материал:
👉 Хореография, брокеры и API Gateway: как строить процессы в распределенных системах
🗓 с 14 до 17 марта (сб-вт)
🔗 Получить доступ
ПОВТОРНО РЕГИСТРИРОВАТЬСЯ НЕ НАДО,
если уже регистрировались на основной эфир!
Письмо с доступом придёт в субботу утром.
👉 Эта встреча была вводным занятием к практической программе Проектирование Архитектуры, которая стартует 17 марта.
🎁 Сегодня последний день действия спецусловий с онлайн-встречи.
Если чувствуете, что сейчас ваш момент идти в более сложные и интересные архитектурные задачи — буду рада видеть вас на программе 🙌
Спасибо вам за доверие!
Искренне ценю вашу вовлечённость и выбор расти в карьере вместе с GetAnalyst! ❤️🔥
С добром и теплом,
Екатерина Ананьева
(P.S. доступ уже открыт - до 17.03)
Коллеги, это абсолютный восторг!
Я была безумно рада провести для вас этот прямой эфир!
Комментарии в картинках к посту ❤️🔥
И честно, такие практики получаются по-настоящему мощными и душевными
👉 не только потому, что я подготовила материал, а потому что это делаете вы.
▫️ Ваши вопросы
▫️ Ваша внимательность к деталям
▫️ Ваше желание разобраться и докопаться до сути, а не пройтись по верхам
▫️ Ваша вовлечённость
Я задала основу, но именно вы сделали этот эфир таким живым, глубоким и действительно полезным.
И вот за это вам огромное спасибо!
👉 Я в очередной раз убеждаюсь, что в GetAnalyst собрались действительно очень сильные специалисты.
Что успели:
🔹 Монолит, SOA, MSA и EDA архитектуры на примерах
🔹 API Gateway — ключевые функции и типичные ошибки в понимании
🔹 Kafka и RabbitMQ — архитектура и когда что выбирать
🔹 Работа с Saga-хореография на практике
И почти по каждому пункту успели погрузиться в детали.
📌 Доступ к записи
Для тех, кому не удалось подключиться, остаться до конца или хочется ещё раз пройти всю практику и закрепить материал:
👉 Хореография, брокеры и API Gateway: как строить процессы в распределенных системах
ПОВТОРНО РЕГИСТРИРОВАТЬСЯ НЕ НАДО,
если уже регистрировались на основной эфир!
Письмо с доступом придёт в субботу утром.
👉 Эта встреча была вводным занятием к практической программе Проектирование Архитектуры, которая стартует 17 марта.
Если чувствуете, что сейчас ваш момент идти в более сложные и интересные архитектурные задачи — буду рада видеть вас на программе 🙌
Спасибо вам за доверие!
Искренне ценю вашу вовлечённость и выбор расти в карьере вместе с GetAnalyst! ❤️🔥
С добром и теплом,
Екатерина Ананьева
Please open Telegram to view this post
VIEW IN TELEGRAM
Please open Telegram to view this post
VIEW IN TELEGRAM
❤🔥32❤13🔥6💯3