Forwarded from 👩🏻💻 Подкаст Системных Аналитиков | GetAnalyst
Разобрали, как low-code внедряют в крупные корпоративные системы: с полноценной разработкой и реальными нагрузками — и как системный аналитик с его помощью двигает продукт наравне с разработчиками.
Обсудили классный проект с голосовым роботом-помощником 🤖
Если вы хотите больше работать с техническими задачами, говорить с разработчиками на одном языке и приносить результат для продукта не только “в требованиях”, а в работающих решениях — этот выпуск для вас!
Эпизод доступен в:
⏯ Apple Podcast
⏯ Яндекс.Музыка
⏯ Telegram
⏯ Castbox
⏯ Звук
⏯ Spotify
⏯ RuTube
⏯ YouTube
⏯ VK Video
🌐 GetAnalyst — профессиональная среда для тех, кто хочет уверенно расти в системном анализе и архитектуре
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥13❤9❤🔥1😢1💯1
This media is not supported in your browser
VIEW IN TELEGRAM
❤11🤣2❤🔥1😱1
А так…. все ссылки собрала для вас тут 🙃
Разрешено в РФ
✅ VK
✅ Мессенджер Max
✅ RuTube
✅ Сайт GetAnalyst.ru
В нестабильной зоне - Telegram:
⚠️ GetAnalyst Навыки - продвинутый уровень
⚠️ Для начинающих в СА и БА
⚠️ Чат сообщества
⚠️ Подкаст (здесь ссылки на все аудио-площадки)
Доступно под VPN:
🔺 Instagram
🔺 LinkedIn
🔺 YouTube
👉 Подписывайтесь сейчас, чтобы не терять доступ к базе знаний GetAnalyst и продолжать ежедневное обучение 🚀
С добром и заботой,
Екатерина Ананьева,
и команда GetAnalyst 🤍
Разрешено в РФ
✅ VK
✅ Мессенджер Max
✅ RuTube
✅ Сайт GetAnalyst.ru
В нестабильной зоне - Telegram:
⚠️ GetAnalyst Навыки - продвинутый уровень
⚠️ Для начинающих в СА и БА
⚠️ Чат сообщества
⚠️ Подкаст (здесь ссылки на все аудио-площадки)
Доступно под VPN:
🔺 YouTube
👉 Подписывайтесь сейчас, чтобы не терять доступ к базе знаний GetAnalyst и продолжать ежедневное обучение 🚀
С добром и заботой,
Екатерина Ананьева,
и команда GetAnalyst 🤍
1❤32👌6🤔1🤣1
Мы умеем быть разными: мягкими, сильными, умными, красивыми — и гораздо глубже, чем просто внешность.
Мы держим в голове десятки задач, замечаем детали, собираем хаос в логику. И часто держим на себе больше, чем о нас принято думать. Не только в работе, но и в жизни.
С 8 марта, дорогие девушки!
Пусть весна и любовь согревают вас, а ваше сияние — всё вокруг 🌸💐🩷☀️
Пусть вас ценят по-настоящему — и в работе, и в жизни! 💙
Мы держим в голове десятки задач, замечаем детали, собираем хаос в логику. И часто держим на себе больше, чем о нас принято думать. Не только в работе, но и в жизни.
С 8 марта, дорогие девушки!
Пусть весна и любовь согревают вас, а ваше сияние — всё вокруг 🌸💐🩷☀️
Пусть вас ценят по-настоящему — и в работе, и в жизни! 💙
2❤74❤🔥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❤8
👉 Сегодня последний день заявок по сниженным ценам и доп. обучением по 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
👍7
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
👍18❤7🔥6
🟢 [Завтра в 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
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
❤21🔥9👍3
🟢 Встречаемся в 19:00 Мск, онлайн 🟢
Практикум по архитектуре для аналитиков:
👉 Хореография, брокеры и API Gateway: как строить процессы в распределенных системах
🔗 Зарегистрироваться
План:
✔️ Глубокое погружение в микросервисы
✔️ Много каверзных вопросов
✔️ Самая важная теория
✔️ Практика
📚 Дополнительные материалы
Обещаю супер-детальную обратную связь и реальный проектный опыт, который будет полезен в работе и для собеседований!
До встречи! 🙌
Практикум по архитектуре для аналитиков:
👉 Хореография, брокеры и API Gateway: как строить процессы в распределенных системах
План:
✔️ Глубокое погружение в микросервисы
✔️ Много каверзных вопросов
✔️ Самая важная теория
✔️ Практика
📚 Дополнительные материалы
Обещаю супер-детальную обратную связь и реальный проектный опыт, который будет полезен в работе и для собеседований!
До встречи! 🙌
Please open Telegram to view this post
VIEW IN TELEGRAM
❤16🔥6🎉2👍1
❗️Коллеги уже через 3 часа❗️
👩💻 Практический вебинар с Екатериной Ананьевой
💎 Хореография, брокеры и API Gateway: как строить процессы в распределенных системах
⏰ 19:00 Мск
🟢 Онлайн
Ссылку на эфир пришлем в канал за 15 минут до начала.
👩💻 Практический вебинар с Екатериной Ананьевой
⏰ 19:00 Мск
🟢 Онлайн
Ссылку на эфир пришлем в канал за 15 минут до начала.
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥6