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

📌✨ Хореография, брокеры и API Gateway: 4,5 часа практики по архитектуре для СА и БА [12-15 сентября] ✨📌

Один пользовательский запрос может запустить цепочку действий сразу в нескольких сервисах.

Что оставить синхронным?
Где использовать брокер?
Какие события передавать?
Как продолжить процесс, если один из сервисов недоступен?

На новом бесплатном практикуме вы не просто изучите термины, а ➡️ пошагово разберётесь в проектировании сквозных процессов в микросервисной архитектуре.


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


👉 Внутри — четыре отдельных урока:

1️⃣ Микросервисы
Как определять их границы и когда разделение системы действительно оправданно.

2️⃣ API Gateway
Роль, ключевые функции, границы ответственности и практика описания процессов.

3️⃣ Kafka и RabbitMQ
Очереди, брокеры сообщений и событийно-ориентированная архитектура.

4️⃣ Saga и хореография
Пошаговое проектирование процесса через несколько микросервисов и асинхронные интеграции.


👉 В результате у вас сложится полноценная архитектурная картинка:

▫️ сервисы и их ответственность
▫️ синхронные API и события
▫️ API Gateway и брокеры
▫️ сквозной процесс и обработка сбоев



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


🔗 Зарегистрироваться на бесплатный практикум



Этот практикум — полноформатное вводное обучение к практической программе «Проектирование архитектуры» для системных аналитиков, которая стартует 15 сентября.

Если захотите продолжить обучение, глубже разобраться в архитектуре и увереннее проектировать сложные процессы — присоединяйтесь 🙌


Вопросы? Пишите @getanalyst или на info@getanalyst.ru.

🔀❌ API Gateway нужен не всегда: 6 способов организовать вход в Backend 🔀❌


API Gateway — это компонент архитектуры, который выступает единой точкой входа для клиентских запросов к backend-системе и перенаправляет их в нужные внутренние сервисы.

Ключевые задачи:
▫️ маршрутизация запросов
▫️ аутентификация и авторизация
▫️ ограничения нагрузки (rate limiting)
▫️ единые логирование и мониторинг
▫️ преобразования запросов/ответов,
▫️ агрегация данных из нескольких сервисов.

При этом API Gateway не владеет данными и не управляет бизнес-процессами. Это его особенность.


На архитектурных схемах перед микросервисами часто "по умолчанию" появляется API Gateway.

✅ Есть микросервисы? Значит, нужен API Gateway.
❌ Но это не обязательное правило.

API Gateway — только один из способов организовать взаимодействие клиентских приложений с Backend.


Важно знать альтернативы:


1️⃣ Прямое обращение к монолиту

Если Backend представляет собой одно приложение, клиент может обращаться непосредственно к нему.

Отдельный API Gateway здесь точно не нужен: маршрутизировать запросы между несколькими Backend-сервисами просто некуда.

При этом перед приложением всё равно могут находиться инфраструктурные компоненты: reverse proxy, load balancer или Ingress.


2️⃣ Сервис-ядро

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

Это аналог оркестратора.

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

Важно правильно назвать такой компонент.

Если он выполняет бизнес-логику и управляет процессами — это сервис-ядро, а не API Gateway.


3️⃣ Прямое обращение к нескольким сервисам

Клиент может вызывать публичные API сервисов напрямую.

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

Но клиент начинает знать внутреннюю структуру Backend. При изменении границ сервисов придётся менять и клиентское приложение.



4️⃣ Backend for Frontend (BFF)

Для каждого типа клиентского приложения создаётся свой Backend:

▫️ BFF для мобильного приложения
▫️ BFF для веб-интерфейса
▫️ BFF для админки

BFF адаптирует данные под конкретный интерфейс и объединяет обращения к нескольким сервисам.

Это особенно полезно, когда у клиентов разные сценарии, модели данных и требования к скорости ответа.

При этом BFF и API Gateway могут использоваться вместе.



5️⃣ Reverse proxy, Load Balancer или Ingress

Если нужно только:

▫️ принять HTTPS-запрос,
▫️ завершить TLS,
▫️ распределить нагрузку,
▫️ направить запрос в нужный сервис,

то может быть достаточно инфраструктурного прокси или Ingress.

Полноценный API Gateway нужен, когда появляются дополнительные задачи: управление API, проверка токенов, rate limiting, квоты, трансформация запросов и централизованные политики доступа.



6️⃣ Интеграционная шина — ESB

В сервис-ориентированной или legacy-архитектуре запрос может поступать через интеграционную шину.

ESB маршрутизирует сообщения, преобразует форматы и протоколы, связывает внутренние и внешние системы.

Но шина — не просто другое название API Gateway или Kafka.

Если перенести в неё всю бизнес-логику и подключить к БД, она станет сложным центральным компонентом, от которого будут зависеть все интеграции.




👉 Как понять, что нужен именно API Gateway?

Берём его, когда необходимо:

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

При этом количество сервисов — не главный критерий.

Пять сервисов с мобильным приложением, партнёрским API и разными моделями доступа могут потребовать Gateway.

А двадцать внутренних сервисов, скрытых в одном Backend, могут не требовать публичного Gateway, а требовать BFF или иного подхода.



А какое решение у вас на проекте?
Делитесь в комментариях 🙏


📱 Tg | 💙 ВК | 💬 Max

🧠 Задача к собеседованию на Senior СА: найдите 5+ ошибок в C4/Container схеме архитектуры 🐞


Коллега приносит вам на ревью C4/Container для нового проекта — платформы сети постаматов, через которую маркетплейсы и интернет-магазины будут доставлять отправления получателям.

Можно ли согласовать эту архитектуру и передать её команде в разработку?

🔗 схема в высоком разрешении
🔗 о проекте


На первый взгляд всё выглядит убедительно:

▫️ определены пользователи и внешние системы,
▫️ выделены микросервисы и базы данных,
▫️ добавлены API Gateway и Kafka,
▫️ подписаны технологии и взаимодействия.

Но на этой схеме архитектуры точно есть проблемы... 🐞🐛🪲


Ошибки спрятаны на двух уровнях:

1️⃣ В использовании нотации C4
2️⃣ В проектировании архитектуры


👉 Задача: за 10 минут найти минимум 5 ошибок.

По каждой напишите в комментариях:
ошибка → архитектурный риск → как исправить

Важно объяснить, что именно из-за неё невозможно понять или что может сломаться в реальной системе.


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

.
.
.
.
.
.
Подсказки 👇
☑️ Технологии
☑️ Использование цветов
☑️ Асинхронный обмен
☑️ API Gateway
☑️ Интеграция через брокер
☑️ Границы системы
☑️ Уведомления
.
.
.
.


Разбор схемы и ответ — опубликую в следующих постах 🔍


👉 Читаемая схема в высоком разрешении:
🔗 ссылка



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

📱 Tg | 💙 ВК | 💬 Max

🚨 Удаляем посты с материалами, книгами и гайдами из канала.
Каждый второй подкаст будет платным.
Бесплатных практикумов по 4+ часа больше не будет.


Примерно так мог бы выглядеть GetAnalyst в любой момент.


У меня случился творческий кризис и я почувствовала, что упёрлась в потолок, мне скучно и дальше движения нет))

Поэтому 2 месяца назад я обратилась за взглядом со стороны к специалисту из США, который работает с многомиллионными аккаунтами в соц сетях. А месяц назад мы провели личную консультацию.


Он изучил все наши соц сети, подкасты, вебинары, практики и в какой-то момент спросил:

«А почему ты до сих пор не монетизировала этот огромный объем своей работы?»

Для рынка это вполне привычная и рабочая модель.

➡️ старый полезный контент убирается из открытого доступа и упаковывается в платный продукт
➡️ самые ценные эпизоды подкаста — по подписке
➡️ большие практики — только платно
➡️ бесплатный вебинар — максимум 60 минут, из которых 20+ продажа продукта


После анализа всего GetAnalyst вывод такой:

«Ты слишком много занимаешься благотворительностью, от этого и творческий кризис» 😅

Рационально я всё понимаю.

Один пост = иногда до 6 часов работы.
Гайд = несколько дней.
Большая онлайн-практика = детальная проработка API, БД, схем, заданий, тестирований и куча времени на подготовку.

Всё, что вы видите — не пересказ ChatGPT.


📌 За 95% материалов GetAnalyst стоит сбор реального опыта и его огромная ручная обработка, от единственного автора.
Меня — Екатерины Ананьевой.


Но делать GetAnalyst по описанной выше модели я не хочу.

У меня изначально была другая стратегия:
📌 минимум продаж и максимум реальной пользы, которую можно получить даже не покупая у нас ничего.


Мне нравится, когда говорят:

«Просто открой GetAnalyst — там всё есть»

Когда наши посты сохраняют для работы.
Когда по гайдам впервые открывают Postman.
Когда подкаст помогает разобраться в новой теме.
Когда бесплатная практика потом реально используется в работе.


Да, возможно, с точки зрения монетизации это не самый эффективный путь 🤷‍♀️

Но пока именно эта стратегия для меня и есть GetAnalyst.


Так что если вы давно со мной знакомы — думаю, вы понимаете, почему мне так сложно было бы сделать иначе ❤️‍🔥


А варианты решения творческого кризиса нашли. Собираю энергию и силы. Буду экспериментировать 🙌

💥 [12-15 сентября] Хореография, брокеры и API Gateway: практикум по архитектуре 💥

Разделить систему на микросервисы? Ок. Построить на них рабочий и устойчивый бизнес-процесс — гораздо сложнее.

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

Senior СА — это не тот, кто просто знает определения Kafka, API Gateway и хореографии. Он понимает, как связать микросервисы в единый процесс, выбрать подходящий способ взаимодействия и описать решение так, чтобы его могла реализовать команда 🙌


Чтобы вы могли разобраться в этом на практике, мы готовим новый архитектурный практикум:


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

📹 Запись
🕘 Смотрите в удобное время


👉 За 4+ часа полноформатного обучения:

✅ Поймёте роль API Gateway в микросервисной архитектуре.
✅ Разберётесь в принципах хореографии процессов на практике.
✅ Научитесь описывать процессы в микросервисной архитектуре.
✅ Поймёте, как использовать брокеры сообщений для интеграций микросервисов.
✅ Сможете уверенно обсуждать архитектурные решения с архитекторами и разработчиками.

🔗 Зарегистрироваться


Хотите начать мыслить не отдельными API-методами, а сквозными процессами всей системы, с пониманием асинхрона и брокеров?

Регистрируйтесь сейчас и планируйте время на обучение заранее!



📱 Tg | 💙 ВК | 💬 Max

👩‍💻 Вайбкодинг для СА: создание приложения с помощью ИИ 🤖🧠

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

Означает ли это, что граница между аналитиком и программистом постепенно исчезает? И станет ли умение создавать решения с помощью ИИ новым обязательным навыком аналитика?

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

🔗 Сайт эпизода
🔗 Приложение: инструмент для БД и SQL


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


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


GetAnalyst — база знаний с нереальным количеством практики в открытом доступе 😍


📱 Tg | 💙 ВК | 💬 Max

💎 Архитектура для СА: открыта предзапись, старт 15 сентября 💎

Вы уже уверенный Middle, Middle+ или Senior. Понимаете процессы, работаете с интеграциями и API.

Микросервисы в теории понятны.
Знаете, зачем нужна Kafka.
Но как спроектировать реальный асинхронный процесс, в котором участвуют несколько сервисов?

🔴 Почему, например, остановка одного сервиса всё ещё блокирует процесс, несмотря на Kafka?

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

Нужно определить, где процесс может продолжаться независимо, где должен ждать и что произойдёт, если ожидание затянется.



От определения микросервисов и выбора технологий — к проектированию процессов между ними. На этом строится наш практический курс «Проектирование архитектуры» для системных аналитиков уровня уверенный Middle / Middle+ / Senior.

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


Что будем делать

▫️ Проектировать архитектуру с нуля: выбирать между монолитом, сервисной и микросервисной архитектурой.
▫️ Описывать архитектуру упрощенными схемами и с помощью нотации C4, чтобы обсуждать решения с командой.
▫️ Выбирать способы взаимодействия: REST, GraphQL, WebSocket и другие.
▫️ Проектировать асинхронные взаимодействия с Kafka и RabbitMQ, работать с вебхуками и описывать требования для разработчиков.


После практики с нами

✔️ Приходите на архитектурный митинг и ведёте его, а не просто участвуете.
✔️ Обосновываете повышение грейда конкретными навыками.
✔️ Проходите технические собеседования и сами выбираете оффер.
✔️ Переходите из проектной разработки в продукт с SOA или микросервисами.
✔️ Закрываете пробелы, которые давно хотели закрыть, и собираете своё публичное портфолио.


Процесс

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

✅ Домашние задания и обратная связь — на всех тарифах. Глубина проверки зависит от тарифа.



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

Предзапись до 11 сентября
🎁 скидка + мини-курс «Интеграции 4.0 — продвинутый уровень» в подарок

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

🧩 7 архитектурных решений, которые аналитик принимает раньше архитектора

«Пользователь заказал товар, курьер загрузил посылку в постамат, пользователь её забрал».

Один процесс. Но сколько вопросов появляется, когда начинаешь его проектировать:

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

И это вопросы, с которыми системный аналитик сталкивается уже при проработке требований — ещё до готовой схемы архитектуры.


Конечно, архитектурные решения принимаются вместе с архитектором и разработчиками.
👉 Но аналитику важно понимать, что именно мы выбираем и как этот выбор влияет на работу системы.


В карточках разбираем 7 таких решений на примере проекта #PostamatGA. Без попытки поставить Kafka между всеми прямоугольниками 😃


📌 Сохраните последнюю карточку — пригодится при обсуждении следующей большой фичи или нового проекта.


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

📱 Tg | 💙 ВК | 💬 Max

🔵🔥 Нотация C4 для архитектуры: теория, 7 примеров и практический видеоурок 🔥🔵

Как показать архитектуру системы так, чтобы её поняли и бизнес, и разработчики?
Нотация моделирования архитектуры C4 поможет.

Собрала в одном посте все материалы по C4: от теории до готовых схем с конкретными примерами 👇👇👇



🎬 Практический видеоурок: C4 за 90 минут

Разбираем уровни Context, Container и Component и наглядно показываем, как проектировать архитектуру на примере двух реальных проектов.

К уроку — полный комплект схем C4 / Context и C4 / Container по каждому проекту: можно посмотреть процесс, а затем изучить результат.

⏯ YouTube
⏯ RuTube
⏯ VK Video
⏯ Telegram

🔗 Статья с доп. материалами




📚 Коротко по теории

C4 — модель описания архитектуры системы на четырёх уровнях.
Каждый следующий раскрывает детали предыдущего.


🔗 Официальный сайт C4
🔗 Нотация С4 — примеры диаграмм и инструменты


1️⃣ C4 / Context — контекст
Система, её интеграции и пользователи.
✔️ Главный прямоугольник - наша система
✔️ Серые прямоугольники вокруг - внешние
✔️ Пользователи

👩‍💻 Полезна бизнес- и техническим специалистам


2️⃣ C4 / Container — контейнеры
Независимые по коду приложения в системе, детализация главного прямоугольника c C4 / Context.
✔️ Пользователи и внешние системы с уровня C4 / Context
✔️ Мобильные, веб- и десктоп приложения
✔️ Сервер-приложения: монолит, сервисы, микросервисы, API Gateway
✔️ Базы данных и файловые хранилища
✔️ Виды API
✔️ Технологии (языки программирования, СУБД, протоколы для API и др)
✔️ Базы данных и файловые хранилища
✔️ Очереди и брокеры

👩‍💻 Полезна архитекторам, разработчикам и системным аналитикам.


3️⃣ C4 / Component — компоненты
Модули кода и зависимости между ними.
Детализирует один из контейнеров с C4 / Container.
На каждый контейнер своя схема.
Отлично подходит для детализации модульного монолита.


4️⃣ C4 / Code — код
На этом уровне детализируют каждый компонент c C4 / Component, показывая его реализацию в коде. Обычно это UML-диаграмма классов или другая визуализация.


🛠 Основные инструменты:
🔗 Draw.io - графический
🔗 Structurizr - код
🔗 MermaidChart - код
🔗 PlantUML - код, самый неудобный


Ключевые элементы нотации для каждого уровня прикреплены в картинках к посту.

Необязательно рисовать все четыре уровня: выбирайте нужную детализацию под задачу и аудиторию.



🖼 Примеры схем архитектуры

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

🔗 RideFlow — заказ такси
🔗 TelMed — телемедицина
🔗 BookingGA — сервис аренды недвижимости
🔗 GreenChargeGA — зарядки для электроавто
🔗 CityGA — поиск мероприятий в городе
🔗 AdFlowGA — рекламный сервис
🔗 Пример архитектуры C4 в Miro




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


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

📱 Tg | 💙 ВК | 💬 Max