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

🔥 Асинхронная интеграция через Webhook и брокер: разбор задачи для Middle+ системного аналитика 🩷

Разницу между polling и webhook сегодня объяснит почти каждый. А потом на столе оказывается реальная задача: внешний ИИ-сервис генерирует видео несколько минут, пользователь всё это время смотрит в интерфейс и видит прогресс по генерации. И теория заканчивается. Где хранить статус? Кто кого опрашивает? Нужен ли тут брокер?

🔗 Страница эпизода

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

Актуален всем, кто проектирует интеграции с внешними сервисами, готовится к техническому собеседованию на Middle+ или хочет перестать выбирать между polling, webhook и брокером наугад 🙌


Видео с демо экрана (рекомендуется):
⏯ YouTube
⏯ RuTube
⏯ VK Video
⏯ Telegram


Аудио:
⏯ Apple Podcast
⏯ Яндекс.Музыка
⏯ Castbox
⏯ Звук
⏯ Spotify


GetAnalyst — сообщество системных и бизнес-аналитиков, которые развиваются на реальных задачах 🌱📈


📱 Tg | 💙 ВК | 💬 Max

📗 Интеграции систем: мини-книга с примерами для СА и БА 📗

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


Интеграция — это организация взаимодействия между системами: обмен данными, вызов функций и совместное выполнение бизнес-процесса..


👉 Пример 1
Платформа по доставке еды хочет отправлять клиенту SMS о процессе доставки.

❔Надо ли этой платформе:
1. Покупать оборудование для отправки SMS?
2. Заключать договоры и делать интеграции со всеми операторами сотовой связи?

Конечно, нет.
Мы подключаем готовый SMS-сервис (например, Unisender) через API — и задача по доставке SMS решена 🙌


👉 Пример 2
Тот же сервис доставки хочет принимать оплату банковскими картами.

❔ Надо ли ему:
1. Реализовывать проверку карты?
2. Поддерживать 3-D Secure?
3. Хранить токены и проходить банковскую сертификацию PCI DSS?

Нет.
Мы просто подключаем готовое решение по API, например, от ТБанка.


Главная идея интеграций:
Если не хочешь "изобретать велосипед", просто подключи (интегрируй) уже готовое решение в свою систему.


👉 Виды интеграций:

1) по окружениям:
▫️ Внешние
▫️ Внутренние

2) по направлению:
▫️ Во внешние системы (к вендорам)
▫️ К нашей системе (партнерские)


👉 Способы обмена данными:
▫️ Синхронный - отправили данные и получили ответ сразу.
▫️ Асинхронный - отправили данные и продолжили работу без ожидания ответа, обработка запроса в фоне.


👉 Основные способы интеграции:
▫️ API
▫️ Библиотеки и SDK
▫️ Брокеры
▫️ Файлы
▫️ Общая БД



📗 Подробнее об интеграциях читайте в прикреплённой мини-книге с картинками и примерами.

Полезна, для детального погружения в тему.

Загружайте и изучайте! 🔖


#ИнтеграцииGA

📱 Tg | 💙 ВК | 💬 Max

🔥 [24.09 в 19:00 Мск] Бесплатный онлайн-практикум: реальная задача по асинхронной интеграции для работы и собеседований 🔥

Что вы ответите, если на собеседовании попросят спроектировать интеграцию с ИИ-сервисом, который обрабатывает сотни заявок, отвечает не сразу и периодически падает?

По такой задаче вас могут погонять по всему: нужен ли брокер, что выбрать — Kafka или RabbitMQ, какие предусмотреть статусы, ретраи, ошибки и защиту от повторной обработки.

Ровно такую задачу мы разберём в следующий ЧТ на практике:


🧡 Асинхронная интеграция с ИИ-сервисом: от архитектуры до требований в Confluence

📅 24 сентября, 19:00 МСК

🟢 Онлайн
🕘 3+ часа практики
❗️ Бесплатно


Спроектируем весь процесс, протестируем реальные вызовы ИИ-сервиса в Postman и оформим требования в Confluence.

Можно будет обсуждать решения, разбирать спорные моменты и совершенно бесплатно погонять меня по теме интеграций — почти как на мок-интервью, только наоборот 🔥


План практики:

1️⃣ Когда синхронного взаимодействия недостаточно
2️⃣ Проектирование архитектуры с брокером
3️⃣ Контракт API: методы, статусы, ошибки
4️⃣ Реальные вызовы ИИ-сервиса в Postman
5️⃣ Документация с ИИ-агентом: требования в Confluence и диаграммы


👉 Зарегистрироваться бесплатно


Впервые с весны встречаемся в прямом эфире.

И это наш первый открытый онлайн-практикум по интеграциям примерно за год. Я уже подготовила задачу и очень жду встречи с вами!

Увидимся через 178 часов! 🤩

📚 Нотация C4: полный гайд по моделированию архитектуры с примерами, разбором ошибок и промптом для ИИ

Я подготовила для вас новую большую статью по нотации C4 — максимально полную и актуальную на 2026 год.

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


В новой статье я максимально подробно разобрала:
✔️ каждый уровень и элемент нотации C4 на примерах
✔️ распространённые ошибки и спорные вопросы
✔️ инструменты для создания диаграмм
✔️ примеры кода для Structurizr
✔️ как строить C4 через AI


👉🔥 Много схем, картинок и практических примеров, готовый код Structurizr и промпт для ИИ.


Это максимально практическое руководство.

С ним можно сесть и самостоятельно разобраться в C4 с нуля или использовать статью как шпаргалку, когда на проекте возникает спорный вопрос.


🔗 Ссылка на статью с полным руководством по нотации C4


Сохраняйте и отправляйте коллегам — теперь у нас есть один большой материал, в котором действительно собрано всё по C4 💙



P.S. На статью потрачено почти 3 года для сбора примеров и 14 часов работы по разработке новых примеров и понятных теоретических материалов.

P.S.S. ❤️‍🔥❤️🔥 и комментарии очень помогут собрать энергию, чтобы делать ещё больше полезного для вас))

P.S.S.S. Это правда крутой материал, теперь буду ссылаться на него в наших обучениях по Интеграциям и Архитектуре.



📱 Tg | 💙 ВК | 💬 Max

«Я сегодня до шести» 🤡

📱 Tg | 💙 ВК | 💬 Max

🚨 Надёжность процессов с брокером: чек-лист для СА

Подключить Kafka или RabbitMQ — ещё не значит сделать процесс надёжным.

Сервис принял сообщение из RabbitMQ, обработал его, изменил данные в БД — и упал до отправки подтверждения обработки ACK. Брокер передаёт сообщение повторно.


👉 Что произойдёт: ничего страшного или заказ создастся дважды?


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

Чек-лист :

1️⃣ Идемпотентность
2️⃣ Retry
3️⃣ DLQ — Dead Letter Queue
4️⃣ Transactional Outbox
5️⃣ Порядок сообщений
6️⃣ Подтверждение обработки: ACK / COMMIT OFFSET
7️⃣ Восстановление после сбоя
8️⃣ Мониторинг


📌 Подробный чек-лист прикреплён к посту.
Сохраняйте и пользуйтесь при разработке требований к асинхронным процессам.

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

📱 Tg | 💙 ВК | 💬 Max

🔔 6 главных событий осени в GetAnalyst, на которые стоит обратить внимание и сохранить в календарь 🍁🔥

Ближайшие недели будут насыщенными!

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


Все даты и ссылки — в одном посте 👇


====================

⏰⏰ Успеть до завтра
[всё по Архитектуре для СА]


✨ Хореография, брокеры и API Gateway:
как проектировать сквозные процессы в микросервисах

Открытый практикум.

📹 4+ часа обучения в записи
🗓 Доступ — до 15 сентября, 23:59 МСК

На примере одного сквозного процесса разберёте микросервисы, API Gateway, Kafka, RabbitMQ и Saga-хореографию.

🔗 Получить бесплатный доступ




👩‍🎓 Проектирование архитектуры

Практическая программа для получения нового опыта работы.

🗓 Старт — 15 сентября
🖥 Первый онлайн-практикум — 22 сентября

🎁 Сегодня последний день сниженных цен

Создана для системных аналитиков Middle+ и старших бизнес-аналитиков, которым важно научиться проектировать архитектуру, а не просто читать готовые схемы.

За три месяца разберём архитектурные шаблоны, API, C4, брокеры, распределённые данные и влияние нефункциональных требований на систему.

🔗 Посмотреть программу и форматы участия




====================

🟢🟢 Ближайшие онлайн-практикумы



📌 Маппинг данных: БД и JSON

🗓 21 сентября, 19:00 МСК
✅ 2.5 часа онлайн
📹 Доступ к записи после

🎁 Урок "Использование AI для проектирования БД + SQL" в подарок.

Будем формировать JSON для API на основе БД и интерфейса, описывать маппинг в требованиях и автоматизировать часть работы с помощью ИИ.

▫️ Стоимость участия от 1 650 руб

🔗 Подключиться к практикуму




🧡 Асинхронная интеграция с ИИ-сервисом:
от архитектуры до требований в Confluence

🗓 24 сентября, 19:00 МСК
✅ 3 часа онлайн

Спроектируем всю цепочку: REST API, очередь, брокер, воркер, статусы, ретраи и ошибки. Затем оформим требования и диаграммы в Confluence с помощью ИИ, и разберём, где он мог ошибиться.

▫️ БЕСПЛАТНО

🔗 Зарегистрироваться бесплатно




====================

🎓🎓 Важные программы осени



🚀 Системный аналитик: с нуля до опыта работы на проекте

🗓 Старт — 1 октября
🟢 Онлайн-практикумы в течение 10 месяцев

Для тех, кто начинает путь в системном анализе, переходит из смежной профессии или хочет систематизировать знания.

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

❗️ Программа проводится только один раз в год.

🔗 Узнать, как проходит обучение




🧡 Интеграции систем

🗓 Старт — 7 октября
🖥 Первый онлайн-практикум — 14 октября

Полный цикл работы аналитика над интеграцией на реальных задачах: от сценариев и выбора API до маппинга, безопасности, UML, асинхронного взаимодействия и постановки задач разработчикам.

❗️ Следующий поток уже в 2027 году.

🔗 Посмотреть программу курса


====================

🎁 Ещё тут дарю бесплатный билет на конференцию Стачка в Питере (3-4 октября) - итоги в конце недели

====================

Не знаете, что выбрать под свой опыт и рабочие задачи? Напишите @getanalyst — поможем сориентироваться.


Всем классной и продуктивной недели! 🥰

📱 Tg | 💙 VK | 💬 Max

Выбор за тобой. Ничего не менять — тоже выбор. И пока ты его делаешь, кто-то другой готовится занять твоё место 👍

📱 Tg | 💙 ВК | 💬 Max

🟢🔥 4 бесплатных занятия по архитектуре — доступ до 15 сентября

Сегодня утром открыли доступ к бесплатному практикуму.

Он поможет перестать мыслить отдельными экранами и API-методами, и начать видеть сквозной процесс целиком — с микросервисами, синхронными и асинхронными взаимодействиями, брокерами и точками отказа:


🧩 Хореография, брокеры и API Gateway:
как проектировать сквозные процессы в микросервисах

Внутри — четыре занятия на примере одной архитектурной задачи:

👉 Урок 1. Микросервисы: как и зачем проектировать
👉 Урок 2. API Gateway
👉 Урок 3. Kafka и RabbitMQ
👉 Урок 4. Saga-Хореография микросервисов: практика


Почему стоит пройти это обучение:

✔️ поймёте, как устроены сквозные процессы в распределённой архитектуре
✔️ разберётесь, где использовать синхронное взаимодействие, а где — брокер и события
✔️ закроете пробелы, которые мешают обсуждать решения с разработчиками и архитекторами на одном языке
✔️ лучше подготовитесь к архитектурным задачам и вопросам на собеседованиях уровня Middle+ / Senior


📹 4,5 часа практического обучения в записи
🕘 Смотреть можно в удобное время

⏰ Доступ закроется 15 сентября в 23:59 МСК


🔗 Получить бесплатный доступ

📩 Если уже зарегистрированы,
проверьте почту — письмо с доступом отправили сегодня утром.

Если зарегистрируетесь сейчас, письмо придёт на указанный адрес.
Если его нет во входящих, проверьте папку «Спам» или напишите @getanalyst.


Продуктивных выходных! 🚀


📱 Tg | 💙 ВК | 💬 Max

📚 Брокеры: полная подборка для системных аналитиков 📚

Делимся с вами подборкой статей, постов и подкастов, которые помогут разобраться с темой:

📌 Брокеры и очереди — общая теория
📚 Очередь сообщений - что это и как работает?
📝 Всё про брокеры: как работают и зачем нужны
📝 Очередь vs Брокер: вопросы с подвохом
📝 Хореография и оркестрация в микросервисной архитектуре
📝 7 вопросов с подвохом по Архитектуре: хореография + понимание брокеров в EDA
📝 Kafka или RabbitMQ: как выбрать брокер под задачу
📝 Надежность процессов с брокером: чек-лист

📌 Kafka
📙 Официальная документация
📝 Kafka - что надо знать для работы СА
📝 Устройство Kafka
📝 Алгоритм работы Kafka
📝 Как встроить Kafka в архитектуру, и главное зачем
📝 Пример использования Kafka - проект #FarmFreshGA
📝 Kafka в деле: подробный разбор примера использования в МСА
🎧 Kafka: что нужно знать Системному аналитику

📌 RabbitMQ
📙 Официальная документация
📝 Брокер RabbitMQ - полный гайд с разбором примера использования в микросервисах
📚 Брокер RabbitMQ - пошаговая практика по развёрыванию и тестированию через CloudAMPQ
🎧 RabbitMQ и его отличия от Kafka: что важно знать системным аналитикам
🎧 Почему падает RabbitMQ: реальный кейс, который должен знать аналитик

📌 Постановки задач / ТЗ
📝 Пример реального интеграционного Use Case: с микросервисами, cron и kafka - проект BookingGA
📝 Пример технического Use Case с брокером в микросервисной архитектуре - проект GreenChargeGA




📚 Книги
▫️ Apache Kafka. Потоковая обработка и анализ данных. Гвен Шапира
▫️ Kafka в действии. Дилан Скотт
▫️ Проектирование событийно-ориентированных систем. Бэн Стопфорд (есть в открытом доступе)



🔖 Пересылайте в Избранное — поможет для структурирования знаний, практики с инструментами, и подготовки к собеседованиям 🤝


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

📱 Tg | 💙 ВК | 💬 Max

🎁🚀 Дарю бесплатный билет на IT-конференцию «Стачка 2026» в СПб, 3–4 октября

Если вы раньше не слышали про Стачку — это большая профессиональная IT-конференция для разработчиков, аналитиков, архитекторов, тестировщиков, руководителей и других IT-специалистов.

В этом году будет 150+ докладов: системный и бизнес-анализ, архитектура, разработка, ML/DS, AI-агенты и много других направлений. А одна из главных тем конференции — как ИИ меняет работу в IT.

📍 Стачка пройдёт 3–4 октября в Санкт-Петербурге.

И у меня есть 1 офлайн-билет, который я хочу отдать кому-то из вас 💙



Сразу главное условие:

❗️ вы будете в Санкт-Петербурге 3–4 октября или готовы самостоятельно приехать на конференцию

Если да — участвуйте 👇



Представьте, что вас позвали выступить на IT-конференции 🎤

👉 Как назывался бы ваш доклад?

Можно серьёзно, можно смешно 😄
Достаточно одного названия в комментариях.

Например:

«Почему webhook — это ещё не асинхронная архитектура»
или
«Как объяснить бизнесу, зачем нам Kafka, и не быть уволенным» 😅

✅ Среди всех участников выберу одного победителя за самое креативное и/или полезное название доклада.
А если вам будет актуально, то обязательно приглашу с этой темой в наш подкаст 😉



Если вы ещё не состоите в чате GetAnalyst и комментарии недоступны, подайте заявку на вступление.
Чтобы я быстрее нашла вашу заявку, напишите @getanalyst в личку кодовое слово «Стачка».



🎟 Победителю — билет на Стачку 2026

➕ Для нашего сообщества организаторы Стачки также дали промокод getanalyst2026 — скидка 20% на билет.


👉 Итоги объявлю 19 сентября, в комментариях + отдельным постом в канале.


P.S. На конференции будет моя коллега 💙
За пару дней до Стачки расскажу, как её найти. Можно будет познакомиться, пообщаться и забрать полезные подарки от GetAnalyst



Погнали 👇

Как назывался бы ваш доклад на IT-конференции?

😡 «Я системный аналитик, а не архитектор»: где реально заканчивается ваша ответственность?

Эту фразу часто слышно, когда в проекте или на собеседовании нужно:

▫️ определить микросервисы
▫️ выбрать синхронное или асинхронное взаимодействие
▫️ решить, нужен ли брокер сообщений
▫️ почитать нагрузку на сервера, чем вообще DevOps-ы занимаются 😱

Если в команде есть Архитектор, финальная ответственность за архитектурное решение обычно лежит на нём.

Но принять такое решение без участия аналитика сложно: именно СА глубоко понимает бизнес-процессы, данные, исключения и зависимости между системами.

Поэтому задача аналитика — не единолично утверждать архитектуру, а участвовать в её проектировании, предлагать варианты и проверять, как выбранное решение будет работать в реальных сценариях



Границы ролей 👇

1️⃣ Зона СА

Системный аналитик отвечает за то, как система должна вести себя в конкретных сценариях:

▫️ какие компоненты участвуют в процессе
▫️ какие данные и в какой момент передаются
▫️ кто владеет данными и изменяет их
▫️ какие методы API, события и статусы нужны
▫️ что произойдёт при ошибке, повторном запросе или недоступности системы
▫️ какие проверки и бизнес-правила должны выполняться

Например, недостаточно написать:
После создания заказа отправить событие в брокер

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

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



2️⃣ Зона СА + Архитектора

Часть решений нельзя корректно принять без понимания полной картины требований:

▫️ выделение сервисов и их границ
▫️ выбор между синхронным и асинхронным взаимодействием
▫️ использование API Gateway и брокеров сообщений
▫️ распределение ответственности за данные
▫️ выбор хореографии или оркестрации
▫️ обеспечение безопасности и отказоустойчивости

Здесь СА приносит бизнес-сценарии, ограничения, данные и варианты решения, которые влияют на итоговую архитектуру.

Архитектор оценивает влияние этих требований на всю систему: связанность компонентов, масштабирование, безопасность, стоимость сопровождения и соответствие архитектурным стандартам.

👉 СА не просто ждёт готовое решение Архитектора. Он участвует в его подготовке и должен уметь предложить и обосновать свой вариант



3️⃣ Зона Архитектора

Архитектор отвечает за согласованность решения на уровне всей системы или нескольких систем:

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

При этом архитектор не обязан самостоятельно описывать каждый метод API, формат события и альтернативный сценарий.

Для этого ему как раз нужен сильный системный аналитик



❗️ Где проходит реальная граница?

По масштабу решения и ответственности за последствия:

🔹 Middle СA проектирует детальное поведение системы и взаимодействия в рамках задачи или подсистемы

🔹 Senior СА предлагает архитектурные варианты, оценивает ограничения и защищает решения перед командой

🔹 Архитектор отвечает за согласованность решения на уровне всей системы и целевого архитектурного ландшафта

👉 На практике эти зоны пересекаются. Особенно в продуктовых командах, где отдельного архитектора может вообще не быть.

Поэтому чем выше уровень СА, тем чаще от него ждут не только требований, но и ответа на архитектурные вопросы.



На практической программе «Проектирование архитектуры» мы развиваем именно эту зону: идём от требований к проектированию сервисов, данных, интеграций и сквозных процессов.


💎 Проектирование архитектуры
🗓 Старт — 15 сентября

Завтра завершается предзапись на спец условиях:
🎁 сниженная цена + «Интеграции 4.0 — продвинутый уровень» в подарок

👉 Посмотреть программу и записаться


✅ Бесплатный вводный практикум

⚔️ Kafka или RabbitMQ: как выбрать брокер под задачу


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


Брокер выбирают по модели взаимодействия:

▫️ что передаём — команду или событие
▫️ сколько получателей должны обработать сообщение
▫️ нужно ли хранить и повторно читать историю
▫️ важны ли маршрутизация, приоритеты и срок жизни сообщений


Разберём по полочкам 👇



🐇 RabbitMQ

RabbitMQ хорошо подходит для передачи команд и фоновых задач, которые должен выполнить конкретный обработчик:

▫️ отправить подтверждение заказа
▫️ зарезервировать товар
▫️ сформировать счёт
▫️ запустить расчёт

Обычно одна задача попадает в очередь, а выполняет её один из свободных обработчиков.

RabbitMQ стоит рассматривать, если:

✅ сообщение предназначено одному исполнителю
✅ нужна гибкая маршрутизация по разным очередям
✅ срочные задачи должны обрабатываться раньше обычных
✅ сообщения требуется удалять после истечения заданного срока
✅ нужны подтверждения обработки, повторные попытки и отдельная очередь (dead-letter) для сообщений, которые не удалось обработать
✅ после успешного выполнения задачи её не потребуется читать повторно.

Оговорка: fanout/topic exchange в RabbitMQ умеет доставлять одно сообщение сразу нескольким независимым очередям — так что «один исполнитель» это типичный сценарий использования, а не жёсткое архитектурное ограничение.



🔥 Kafka

Kafka подходит для передачи бизнес-событий — фактов, которые уже произошли:

▫️ заказ создан
▫️ оплата подтверждена
▫️ заказ отменён
▫️ доставка завершена

Одно событие могут независимо обработать несколько систем.

Например, событие «Заказ создан» получают:

📦 сервис склада — резервирует товар
💳 сервис оплаты — создаёт платёж
🔔 сервис уведомлений — сообщает пользователю
📊 аналитическая система — обновляет показатели

Kafka стоит рассматривать, если:

✅ одно событие нужно нескольким независимым получателям
✅ события необходимо хранить и перечитывать
✅ новый получатель должен обработать ранее опубликованные события
✅ по истории событий потребуется восстановить состояние сервиса
✅ данные используются для аудита, аналитики или отслеживания изменений
✅ система обрабатывает большой непрерывный поток событий.

Оговорка: хранение в Kafka не бесконечное по умолчанию — период (retention) настраивается отдельно. Если нужно хранить события вечно (что не хорошо для Kafka) — это отдельное архитектурное решение (compacted topic), а не поведение "из коробки".




👉 7 вопросов перед выбором

1️⃣ Передаём команду или событие?

«Выполни действие» → чаще RabbitMQ
«Действие уже произошло» → чаще Kafka


2️⃣ Сколько получателей должны обработать сообщение?

Одну задачу выполняет один из доступных обработчиков → RabbitMQ.
Каждый вид получателей должен независимо получить событие → Kafka (либо RabbitMQ через fanout-exchange, если история не нужна)


3️⃣ Нужно ли перечитывать историю?

Если после успешной обработки сообщение больше не требуется → RabbitMQ.
Если сообщения нужно хранить, повторно обрабатывать или передавать новым получателям → Kafka


4️⃣ Нужна ли сложная маршрутизация?

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

В Kafka распределение строится через темы, разделы, ключи сообщений и группы получателей.


5️⃣ Важен ли порядок событий?

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

В RabbitMQ на порядок могут повлиять несколько обработчиков, повторная доставка и приоритеты.


6️⃣ Что важнее: распределение задач или история событий?

Распределить задания между исполнителями → RabbitMQ.
Сохранить поток событий для нескольких систем → Kafka.


7️⃣ Готова ли команда поддерживать выбранный брокер?

▫️ инфраструктура
▫️ опыт команды
▫️ требования к отказоустойчивости
▫️ стоимость сопровождения
▫️ возможности мониторинга



👉 В одной системе можно использовать оба брокера.
Но только тогда, когда системе действительно нужны обе модели взаимодействия.


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

📚 Задача с собеседования на Senior СА: 10 ошибок и 1 ловушка в схеме архитектуры 📚

Публикую ответ к задаче на ревью C4/Container-схемы архитектуры платформы постаматов. Подобную задачу могут предложить на собеседовании системного аналитика.


Вот что было спрятано на схеме👇


1️⃣ Непоследовательное использование цветов

Курьер показан серым, хотя он взаимодействует с нашей системой. Его нужно оформить как остальных пользователей либо объяснить различие в легенде.


2️⃣ Нестандартная форма API Gateway не объяснена

Шестиугольник допустим как авторское обозначение, но его значение необходимо закрепить в легенде или обговорить в команде. В C4 нет правила «API Gateway — шестиугольник».


3️⃣ В подписях связей осталось e.g.

e.g. JSON/HTTP — это пример из шаблона, а не описание интеграции. На схеме должны быть указаны фактические данные и протокол: JSON/HTTPS, Protobuf/gRPC, JSON/Kafka protocol и другие.


4️⃣ Неверно обозначена граница системы

Контур подписан как Container, хотя внутри уже находятся контейнеры. Это граница Software System, в которую также должны входить приложение постамата и административная панель.


5️⃣ Два API Gateway без обоснованной необходимости

Для семи сервисов Public API Gateway и Admin API Gateway создают лишнюю сложность. В рамках задачи достаточно одного Gateway с разными маршрутами и политиками доступа.


6️⃣ Маркетплейс напрямую подключён к внутренней Kafka

Внешняя система не должна знать внутреннее устройство backend. В этой задаче запросы маркетплейса принимаем через REST API и публичный API Gateway, а изменения статусов передаём через Webhooks. Это более универсальное и применимое решение, чем брокер.


7️⃣ Постамат обращается напрямую к сервису

Если аутентификация и другие общие проверки настроены на API Gateway, прямой маршрут позволяет их обойти.

В предложенном решении устройства подключаются через защищённую точку входа с аутентификацией и проверкой прав конкретного постамата. Для MQTT может использоваться специализированный IoT- или MQTT-шлюз, либо общий шлюз с поддержкой MQTT.

В данной схеме это не то, чтобы ошибка, но точно место, на которое стоит обратить внимание.


8️⃣ Уведомления отправляются синхронно

Недоступность SMS- или email-провайдера не должна останавливать основной процесс. События передаём через Kafka или RabbitMQ, а сервис уведомлений обрабатывает их независимо.


9️⃣ Firebase добавлен без бизнес-сценария

У системы нет собственного клиентского приложения для получателя. Push-уведомления отправлять некуда, поэтому Firebase в текущей архитектуре не нужен.


🔟 Планировщик запускает задачи синхронно

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


✅ Общая БД — ловушка, а не ошибка

У неопытных аналитиков часто встречается правило:
«Если микросервисы, то каждому обязательно нужна отдельная физическая БД».
Но это не так.

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

Ошибка возникает, когда сервисы напрямую читают или изменяют чужие таблицы и границы владения данными фактически отсутствуют.



Все материалы по задаче:

📚🔥 Полный разбор с пояснениями
✔️ Исходная схема
✔️ Схема с отмеченными ошибками
✔️ Исправленная схема архитектуры

Доступны по ссылке + прикреплены к посту.


Сохраняйте разбор в личный архив — пригодится для подготовки к собеседованиям и работы с реальной архитектурой 🔖


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