В микросервисах важны не только сервисы, но и связи между ними. Если интеграции не продуманы — данные расходятся, появляются дубли, а разбор инцидентов превращается в хаос.
Чтобы вы на практике научились проектировать такие процессы, мы готовим новый открытый онлайн-практикум:
🟢 Онлайн
План практикума:
1. Как и зачем проектировать микросервисы
2. API Gateway: роль в архитектуре и границы ответственности
3. Введение в брокеры сообщений: Kafka
4. Хореография микросервисов: практика описания процессов через события
Урок будет полезен, если вы:
• готовитесь к интервью на Middle+ / Senior СА,
• хотите расширить техническую базу и работать с архитектурными задачами,
• или стремитесь работать в команде, где микросервисы — это реальность, а не теория.
Нужен реальный опыт в архитектуре?
Регистрируйтесь и присоединяйтесь к эфиру 12 марта в 19:00 Мск! 🔥
———
Онлайн-практикум является вводным уроком к программе Проектирование архитектуры для системных аналитиков, которая стартует 17 марта.
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥18❤7
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
🔥12❤9❤🔥1😢1💯1
This media is not supported in your browser
VIEW IN TELEGRAM
❤9🤣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❤29👌5🤔1🤣1
Мы умеем быть разными: мягкими, сильными, умными, красивыми — и гораздо глубже, чем просто внешность.
Мы держим в голове десятки задач, замечаем детали, собираем хаос в логику. И часто держим на себе больше, чем о нас принято думать. Не только в работе, но и в жизни.
С 8 марта, дорогие девушки!
Пусть весна и любовь согревают вас, а ваше сияние — всё вокруг 🌸💐🩷☀️
Пусть вас ценят по-настоящему — и в работе, и в жизни! 💙
Мы держим в голове десятки задач, замечаем детали, собираем хаос в логику. И часто держим на себе больше, чем о нас принято думать. Не только в работе, но и в жизни.
С 8 марта, дорогие девушки!
Пусть весна и любовь согревают вас, а ваше сияние — всё вокруг 🌸💐🩷☀️
Пусть вас ценят по-настоящему — и в работе, и в жизни! 💙
2❤72❤🔥19🎉8🍾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
👍14🔥4❤2