GetAnalyst - Навыки • Системный анализ • Бизнес-анализ
Ir al canal en Telegram
Разбор задач на проектирование систем 🚀 Канал для системных аналитиков, бизнес-аналитиков, тестировщиков и менеджеров проектов Админ @getanalyst Сайт https://getanalyst.ru Чат t.me/getanalystchat Начинающим в IT @getanalyststart
Mostrar más📈 Análisis del canal de Telegram GetAnalyst - Навыки • Системный анализ • Бизнес-анализ
El canal GetAnalyst - Навыки • Системный анализ • Бизнес-анализ (@getanalysts) en el segmento lingüístico de Ruso es un actor destacado. Actualmente la comunidad reúne a 22 438 suscriptores, ocupando la posición 5 744 en la categoría Tecnologías y Aplicaciones y el puesto 29 085 en la región Rusia.
📊 Métricas de audiencia y dinámica
Desde su creación el невідомо, el proyecto ha mostrado un crecimiento acelerado, reuniendo a 22 438 suscriptores.
Según los últimos datos del 15 septiembre, 2026, el canal mantiene una actividad estable. En los últimos 30 días la variación de miembros fue de 134, y en las últimas 24 horas de 9, conservando un alto alcance.
- Estado de verificación: No verificado
- Tasa de interacción (ER): El promedio de interacción de la audiencia es 13.28%. Durante las primeras 24 horas tras publicar, el contenido suele obtener 7.41% de reacciones respecto al total de suscriptores.
- Alcance de las publicaciones: Cada publicación recibe en promedio 2 977 visualizaciones. En el primer día suele acumular 1 661 visualizaciones.
- Reacciones e interacción: La audiencia responde de forma activa: el promedio de reacciones por publicación es 54.
- Intereses temáticos: El contenido se centra en temas clave como api, брокер, архитектура, oauth, микросервисов.
📝 Descripción y política de contenido
El autor describe el recurso como un espacio para expresar opiniones subjetivas:
“Разбор задач на проектирование систем 🚀 Канал для системных аналитиков, бизнес-аналитиков, тестировщиков и менеджеров проектов
Админ @getanalyst
Сайт https://getanalyst.ru
Чат t.me/getanalystchat
Начинающим в IT @getanalyststart”
Gracias a la alta frecuencia de actualizaciones (últimos datos recibidos el 16 septiembre, 2026), el canal mantiene la vigencia y un amplio alcance. La analítica demuestra que la audiencia interactúa activamente con el contenido, lo que lo convierte en un punto de referencia dentro de la categoría Tecnologías y Aplicaciones.
22 438
Suscriptores
+924 horas
+377 días
+13430 días
Carga de datos en curso...
Canales Similares
Nube de Etiquetas
Menciones Entrantes y Salientes
---
---
---
---
---
---
Atraer Suscriptores
septiembre '26
septiembre '26
+152
en 3 canales
agosto '26
+285
en 3 canales
Get PRO
julio '26
+335
en 2 canales
Get PRO
junio '26
+388
en 4 canales
Get PRO
mayo '26
+540
en 5 canales
Get PRO
abril '26
+551
en 3 canales
Get PRO
marzo '26
+477
en 5 canales
Get PRO
febrero '26
+526
en 3 canales
Get PRO
enero '26
+675
en 4 canales
Get PRO
diciembre '25
+481
en 5 canales
Get PRO
noviembre '25
+512
en 5 canales
Get PRO
octubre '25
+545
en 4 canales
Get PRO
septiembre '25
+597
en 5 canales
Get PRO
agosto '25
+840
en 4 canales
Get PRO
julio '25
+520
en 3 canales
Get PRO
junio '25
+441
en 4 canales
Get PRO
mayo '25
+541
en 5 canales
Get PRO
abril '25
+596
en 4 canales
Get PRO
marzo '25
+666
en 5 canales
Get PRO
febrero '25
+724
en 5 canales
Get PRO
enero '25
+678
en 3 canales
Get PRO
diciembre '24
+639
en 4 canales
Get PRO
noviembre '24
+632
en 2 canales
Get PRO
octubre '24
+714
en 2 canales
Get PRO
septiembre '24
+726
en 3 canales
Get PRO
agosto '24
+743
en 3 canales
Get PRO
julio '24
+741
en 2 canales
Get PRO
junio '24
+699
en 2 canales
Get PRO
mayo '24
+773
en 3 canales
Get PRO
abril '24
+852
en 2 canales
Get PRO
marzo '24
+654
en 2 canales
Get PRO
febrero '24
+605
en 2 canales
Get PRO
enero '24
+589
en 1 canales
Get PRO
diciembre '23
+514
en 0 canales
Get PRO
noviembre '23
+565
en 1 canales
Get PRO
octubre '23
+476
en 1 canales
Get PRO
septiembre '23
+532
en 0 canales
Get PRO
agosto '23
+399
en 0 canales
Get PRO
julio '23
+419
en 0 canales
Get PRO
junio '23
+341
en 0 canales
Get PRO
mayo '23
+230
en 0 canales
Get PRO
abril '23
+182
en 0 canales
Get PRO
marzo '23
+212
en 0 canales
Get PRO
febrero '23
+69
en 0 canales
Get PRO
enero '23
+75
en 0 canales
Get PRO
diciembre '22
+152
en 0 canales
Get PRO
noviembre '22
+216
en 0 canales
Get PRO
octubre '22
+140
en 0 canales
Get PRO
septiembre '22
+72
en 0 canales
Get PRO
agosto '22
+158
en 0 canales
Get PRO
julio '22
+116
en 0 canales
Get PRO
junio '22
+167
en 0 canales
Get PRO
mayo '22
+299
en 0 canales
Get PRO
abril '22
+652
en 0 canales
| Fecha | Crecimiento de Suscriptores | Menciones | Canales | |
| 16 septiembre | +21 | |||
| 15 septiembre | +10 | |||
| 14 septiembre | +6 | |||
| 13 septiembre | +10 | |||
| 12 septiembre | +6 | |||
| 11 septiembre | +3 | |||
| 10 septiembre | +5 | |||
| 09 septiembre | +22 | |||
| 08 septiembre | +13 | |||
| 07 septiembre | +15 | |||
| 06 septiembre | +6 | |||
| 05 septiembre | +4 | |||
| 04 septiembre | +11 | |||
| 03 septiembre | +9 | |||
| 02 septiembre | +6 | |||
| 01 septiembre | +5 |
Publicaciones del Canal
📚 Нотация 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
| 2 |  «Я сегодня до шести» 🤡
📱 Tg | 💙 ВК | 💬 Max | 2 515 |
| 3 | 🚨 Надёжность процессов с брокером: чек-лист для СА
Подключить 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 | 2 642 |
| 4 |  🔔 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 году.
🔗 Посмотреть программу курса
====================
Не знаете, что выбрать под свой опыт и рабочие задачи? Напишите @getanalyst — поможем сориентироваться.
Всем классной и продуктивной недели! 🥰
📱 Tg | 💙 VK | 💬 Max | 2 104 |
| 5 |  +6Выбор за тобой. Ничего не менять — тоже выбор. И пока ты его делаешь, кто-то другой готовится занять твоё место 👍
📱 Tg | 💙 ВК | 💬 Max | 2 223 |
| 6 |  🟢🔥 4 бесплатных занятия по архитектуре — доступ до 15 сентября
Сегодня утром открыли доступ к бесплатному практикуму.
Он поможет перестать мыслить отдельными экранами и API-методами, и начать видеть сквозной процесс целиком — с микросервисами, синхронными и асинхронными взаимодействиями, брокерами и точками отказа:
🧩 Хореография, брокеры и API Gateway:
как проектировать сквозные процессы в микросервисах
Внутри — четыре занятия на примере одной архитектурной задачи:
👉 Урок 1. Микросервисы: как и зачем проектировать
👉 Урок 2. API Gateway
👉 Урок 3. Kafka и RabbitMQ
👉 Урок 4. Saga-Хореография микросервисов: практика
Почему стоит пройти это обучение:
✔️ поймёте, как устроены сквозные процессы в распределённой архитектуре
✔️ разберётесь, где использовать синхронное взаимодействие, а где — брокер и события
✔️ закроете пробелы, которые мешают обсуждать решения с разработчиками и архитекторами на одном языке
✔️ лучше подготовитесь к архитектурным задачам и вопросам на собеседованиях уровня Middle+ / Senior
📹 4,5 часа практического обучения в записи
🕘 Смотреть можно в удобное время
⏰ Доступ закроется 15 сентября в 23:59 МСК
🔗 Получить бесплатный доступ
📩 Если уже зарегистрированы,
проверьте почту — письмо с доступом отправили сегодня утром.
Если зарегистрируетесь сейчас, письмо придёт на указанный адрес.
Если его нет во входящих, проверьте папку «Спам» или напишите @getanalyst.
Продуктивных выходных! 🚀
📱 Tg | 💙 ВК | 💬 Max | 2 304 |
| 7 |  📚 Брокеры: полная подборка для системных аналитиков 📚
Делимся с вами подборкой статей, постов и подкастов, которые помогут разобраться с темой:
📌 Брокеры и очереди — общая теория
📚 Очередь сообщений - что это и как работает?
📝 Всё про брокеры: как работают и зачем нужны
📝 Очередь 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 | 2 660 |
| 8 |  🎁🚀 Дарю бесплатный билет на 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-конференции? | 2 625 |
| 9 |  😡 «Я системный аналитик, а не архитектор»: где реально заканчивается ваша ответственность?
Эту фразу часто слышно, когда в проекте или на собеседовании нужно:
▫️ определить микросервисы
▫️ выбрать синхронное или асинхронное взаимодействие
▫️ решить, нужен ли брокер сообщений
▫️ почитать нагрузку на сервера, чем вообще DevOps-ы занимаются 😱
Если в команде есть Архитектор, финальная ответственность за архитектурное решение обычно лежит на нём.
Но принять такое решение без участия аналитика сложно: именно СА глубоко понимает бизнес-процессы, данные, исключения и зависимости между системами.
Поэтому задача аналитика — не единолично утверждать архитектуру, а участвовать в её проектировании, предлагать варианты и проверять, как выбранное решение будет работать в реальных сценариях
Границы ролей 👇
1️⃣ Зона СА
Системный аналитик отвечает за то, как система должна вести себя в конкретных сценариях:
▫️ какие компоненты участвуют в процессе
▫️ какие данные и в какой момент передаются
▫️ кто владеет данными и изменяет их
▫️ какие методы API, события и статусы нужны
▫️ что произойдёт при ошибке, повторном запросе или недоступности системы
▫️ какие проверки и бизнес-правила должны выполняться
Например, недостаточно написать:
После создания заказа отправить событие в брокер
Нужно определить:
+ какое именно событие публикуется
+ какие данные оно содержит
+ кто его получает
+ можно ли обработать его повторно
+ что произойдёт, если получатель временно недоступен
+ когда процесс считается завершённым
👉 Это проектирование поведения системы с учетом особенностей архитектуры — прямая зона ответственности системного аналитика
2️⃣ Зона СА + Архитектора
Часть решений нельзя корректно принять без понимания полной картины требований:
▫️ выделение сервисов и их границ
▫️ выбор между синхронным и асинхронным взаимодействием
▫️ использование API Gateway и брокеров сообщений
▫️ распределение ответственности за данные
▫️ выбор хореографии или оркестрации
▫️ обеспечение безопасности и отказоустойчивости
Здесь СА приносит бизнес-сценарии, ограничения, данные и варианты решения, которые влияют на итоговую архитектуру.
Архитектор оценивает влияние этих требований на всю систему: связанность компонентов, масштабирование, безопасность, стоимость сопровождения и соответствие архитектурным стандартам.
👉 СА не просто ждёт готовое решение Архитектора. Он участвует в его подготовке и должен уметь предложить и обосновать свой вариант
3️⃣ Зона Архитектора
Архитектор отвечает за согласованность решения на уровне всей системы или нескольких систем:
▫️ целевую схему архитектуры
▫️ организацию кода
▫️ технологии
▫️ взаимодействие между компонентами
▫️ масштабирование и отказоустойчивость
▫️ безопасность
▫️ инфраструктурные требования
▫️ стоимость и сложность сопровождения
▫️ согласованность архитектурных решений между командами.
При этом архитектор не обязан самостоятельно описывать каждый метод API, формат события и альтернативный сценарий.
Для этого ему как раз нужен сильный системный аналитик
❗️ Где проходит реальная граница?
По масштабу решения и ответственности за последствия:
🔹 Middle СA проектирует детальное поведение системы и взаимодействия в рамках задачи или подсистемы
🔹 Senior СА предлагает архитектурные варианты, оценивает ограничения и защищает решения перед командой
🔹 Архитектор отвечает за согласованность решения на уровне всей системы и целевого архитектурного ландшафта
👉 На практике эти зоны пересекаются. Особенно в продуктовых командах, где отдельного архитектора может вообще не быть.
Поэтому чем выше уровень СА, тем чаще от него ждут не только требований, но и ответа на архитектурные вопросы.
На практической программе «Проектирование архитектуры» мы развиваем именно эту зону: идём от требований к проектированию сервисов, данных, интеграций и сквозных процессов.
💎 Проектирование архитектуры
🗓 Старт — 15 сентября
Завтра завершается предзапись на спец условиях:
🎁 сниженная цена + «Интеграции 4.0 — продвинутый уровень» в подарок
👉 Посмотреть программу и записаться
✅ Бесплатный вводный практикум | 3 080 |
| 10 |  ⚔️ 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 | 2 848 |
| 11 | +3 📚 Задача с собеседования на 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 | 2 739 |
| 12 | ![📌✨ Хореография, брокеры и API Gateway: 4,5 часа практики по архитектуре для СА и БА [12-15 сентября] ✨📌 Один пользовательск](data:image/jpeg;base64,/9j/4AAQSkZJRgABAQAAAQABAAD/2wBDACgcHiMeGSgjISMtKygwPGRBPDc3PHtYXUlkkYCZlo+AjIqgtObDoKrarYqMyP/L2u71////m8H////6/+b9//j/2wBDASstLTw1PHZBQXb4pYyl+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj/wAARCAAXACgDASIAAhEBAxEB/8QAHwAAAQUBAQEBAQEAAAAAAAAAAAECAwQFBgcICQoL/8QAtRAAAgEDAwIEAwUFBAQAAAF9AQIDAAQRBRIhMUEGE1FhByJxFDKBkaEII0KxwRVS0fAkM2JyggkKFhcYGRolJicoKSo0NTY3ODk6Q0RFRkdISUpTVFVWV1hZWmNkZWZnaGlqc3R1dnd4eXqDhIWGh4iJipKTlJWWl5iZmqKjpKWmp6ipqrKztLW2t7i5usLDxMXGx8jJytLT1NXW19jZ2uHi4+Tl5ufo6erx8vP09fb3+Pn6/8QAHwEAAwEBAQEBAQEBAQAAAAAAAAECAwQFBgcICQoL/8QAtREAAgECBAQDBAcFBAQAAQJ3AAECAxEEBSExBhJBUQdhcRMiMoEIFEKRobHBCSMzUvAVYnLRChYkNOEl8RcYGRomJygpKjU2Nzg5OkNERUZHSElKU1RVVldYWVpjZGVmZ2hpanN0dXZ3eHl6goOEhYaHiImKkpOUlZaXmJmaoqOkpaanqKmqsrO0tba3uLm6wsPExcbHyMnK0tPU1dbX2Nna4uPk5ebn6Onq8vP09fb3+Pn6/9oADAMBAAIRAxEAPwBQrMMqhOOuBmnLEe6t/wB8GnQShfkZQwYjrUzxqeVCLj0UVUpcp0zlJOxB5X+y3/fBpjxHqqufbYam2LnggfSMdKkSNB94IwOOqihVbGXMyg6OoyyFR7jFFTXU+/8AdqoUITjFFdUW2r2C7I+mDmoXQs2d7AdsNiiismro2lqg2nYASemCc01U2tkMx+pzRRVRgrmLQ8kduaKKK2Ef/9k=){kind=small} 📌✨ Хореография, брокеры и 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. | 2 695 |
| 13 |  🔀❌ 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 | 2 532 |
| 14 |  🧠 Задача к собеседованию на Senior СА: найдите 5+ ошибок в C4/Container схеме архитектуры 🐞
Коллега приносит вам на ревью C4/Container для нового проекта — платформы сети постаматов, через которую маркетплейсы и интернет-магазины будут доставлять отправления получателям.
Можно ли согласовать эту архитектуру и передать её команде в разработку?
🔗 схема в высоком разрешении
🔗 о проекте
На первый взгляд всё выглядит убедительно:
▫️ определены пользователи и внешние системы,
▫️ выделены микросервисы и базы данных,
▫️ добавлены API Gateway и Kafka,
▫️ подписаны технологии и взаимодействия.
Но на этой схеме архитектуры точно есть проблемы... 🐞🐛🪲
Ошибки спрятаны на двух уровнях:
1️⃣ В использовании нотации C4
2️⃣ В проектировании архитектуры
👉 Задача: за 10 минут найти минимум 5 ошибок.
По каждой напишите в комментариях:
ошибка → архитектурный риск → как исправить
Важно объяснить, что именно из-за неё невозможно понять или что может сломаться в реальной системе.
👉 Если видите больше пяти, то пишите все.
Некоторые ошибки здесь спрятаны глубже, чем кажется на первый взгляд.
.
.
.
.
.
.
Подсказки 👇
☑️ Технологии
☑️ Использование цветов
☑️ Асинхронный обмен
☑️ API Gateway
☑️ Интеграция через брокер
☑️ Границы системы
☑️ Уведомления
.
.
.
.
Разбор схемы и ответ — опубликую в следующих постах 🔍
👉 Читаемая схема в высоком разрешении:
🔗 ссылка
#PostamatGA #АрхитектураGA
📱 Tg | 💙 ВК | 💬 Max | 3 033 |
| 15 |  🚨 Удаляем посты с материалами, книгами и гайдами из канала.
Каждый второй подкаст будет платным.
Бесплатных практикумов по 4+ часа больше не будет.
Примерно так мог бы выглядеть GetAnalyst в любой момент.
У меня случился творческий кризис и я почувствовала, что упёрлась в потолок, мне скучно и дальше движения нет))
Поэтому 2 месяца назад я обратилась за взглядом со стороны к специалисту из США, который работает с многомиллионными аккаунтами в соц сетях. А месяц назад мы провели личную консультацию.
Он изучил все наши соц сети, подкасты, вебинары, практики и в какой-то момент спросил:
«А почему ты до сих пор не монетизировала этот огромный объем своей работы?»
Для рынка это вполне привычная и рабочая модель.
➡️ старый полезный контент убирается из открытого доступа и упаковывается в платный продукт
➡️ самые ценные эпизоды подкаста — по подписке
➡️ большие практики — только платно
➡️ бесплатный вебинар — максимум 60 минут, из которых 20+ продажа продукта
После анализа всего GetAnalyst вывод такой:
«Ты слишком много занимаешься благотворительностью, от этого и творческий кризис» 😅
Рационально я всё понимаю.
Один пост = иногда до 6 часов работы.
Гайд = несколько дней.
Большая онлайн-практика = детальная проработка API, БД, схем, заданий, тестирований и куча времени на подготовку.
Всё, что вы видите — не пересказ ChatGPT.
📌 За 95% материалов GetAnalyst стоит сбор реального опыта и его огромная ручная обработка, от единственного автора.
Меня — Екатерины Ананьевой.
Но делать GetAnalyst по описанной выше модели я не хочу.
У меня изначально была другая стратегия:
📌 минимум продаж и максимум реальной пользы, которую можно получить даже не покупая у нас ничего.
Мне нравится, когда говорят:
«Просто открой GetAnalyst — там всё есть»
Когда наши посты сохраняют для работы.
Когда по гайдам впервые открывают Postman.
Когда подкаст помогает разобраться в новой теме.
Когда бесплатная практика потом реально используется в работе.
Да, возможно, с точки зрения монетизации это не самый эффективный путь 🤷♀️
Но пока именно эта стратегия для меня и есть GetAnalyst.
Так что если вы давно со мной знакомы — думаю, вы понимаете, почему мне так сложно было бы сделать иначе ❤️🔥
А варианты решения творческого кризиса нашли. Собираю энергию и силы. Буду экспериментировать 🙌 | 3 338 |
| 16 | ![💥 [12-15 сентября] Хореография, брокеры и API Gateway: практикум по архитектуре 💥 Разделить систему на микросервисы? Ок. По](data:image/jpeg;base64,/9j/4AAQSkZJRgABAQAAAQABAAD/2wBDACgcHiMeGSgjISMtKygwPGRBPDc3PHtYXUlkkYCZlo+AjIqgtObDoKrarYqMyP/L2u71////m8H////6/+b9//j/2wBDASstLTw1PHZBQXb4pYyl+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj/wAARCAAXACgDASIAAhEBAxEB/8QAHwAAAQUBAQEBAQEAAAAAAAAAAAECAwQFBgcICQoL/8QAtRAAAgEDAwIEAwUFBAQAAAF9AQIDAAQRBRIhMUEGE1FhByJxFDKBkaEII0KxwRVS0fAkM2JyggkKFhcYGRolJicoKSo0NTY3ODk6Q0RFRkdISUpTVFVWV1hZWmNkZWZnaGlqc3R1dnd4eXqDhIWGh4iJipKTlJWWl5iZmqKjpKWmp6ipqrKztLW2t7i5usLDxMXGx8jJytLT1NXW19jZ2uHi4+Tl5ufo6erx8vP09fb3+Pn6/8QAHwEAAwEBAQEBAQEBAQAAAAAAAAECAwQFBgcICQoL/8QAtREAAgECBAQDBAcFBAQAAQJ3AAECAxEEBSExBhJBUQdhcRMiMoEIFEKRobHBCSMzUvAVYnLRChYkNOEl8RcYGRomJygpKjU2Nzg5OkNERUZHSElKU1RVVldYWVpjZGVmZ2hpanN0dXZ3eHl6goOEhYaHiImKkpOUlZaXmJmaoqOkpaanqKmqsrO0tba3uLm6wsPExcbHyMnK0tPU1dbX2Nna4uPk5ebn6Onq8vP09fb3+Pn6/9oADAMBAAIRAxEAPwCALlTgEn2p6R5Pz5H/AAEmp7GVFDo4OG54qw5hP3Qw+pJ/rW86vK7EpFPyk9T/AN8GmPHg/Lk/8BIq5lAcgkHr0PX/AL6pR5ZPz7iPbI/rUKuOxRZcIOGDZ9KKs3ssflrHGGHO7k5orohJyVyWirvHlbdo69e9RsuW+8wHbBooonHQBcDbg5z65pAuG4ZiP9o0UVEYJNDJMrsxjnPWiiithH//2Q==){kind=small} 💥 [12-15 сентября] Хореография, брокеры и API Gateway: практикум по архитектуре 💥
Разделить систему на микросервисы? Ок. Построить на них рабочий и устойчивый бизнес-процесс — гораздо сложнее.
Именно здесь начинается сеньорский уровень работы системного аналитика.
Senior СА — это не тот, кто просто знает определения Kafka, API Gateway и хореографии. Он понимает, как связать микросервисы в единый процесс, выбрать подходящий способ взаимодействия и описать решение так, чтобы его могла реализовать команда 🙌
Чтобы вы могли разобраться в этом на практике, мы готовим новый архитектурный практикум:
🧩 Хореография, брокеры и API Gateway:
как проектировать сквозные процессы в микросервисах
📅 Доступ с 12 по 15 сентября
📹 Запись
🕘 Смотрите в удобное время
👉 За 4+ часа полноформатного обучения:
✅ Поймёте роль API Gateway в микросервисной архитектуре.
✅ Разберётесь в принципах хореографии процессов на практике.
✅ Научитесь описывать процессы в микросервисной архитектуре.
✅ Поймёте, как использовать брокеры сообщений для интеграций микросервисов.
✅ Сможете уверенно обсуждать архитектурные решения с архитекторами и разработчиками.
🔗 Зарегистрироваться
Хотите начать мыслить не отдельными API-методами, а сквозными процессами всей системы, с пониманием асинхрона и брокеров?
Регистрируйтесь сейчас и планируйте время на обучение заранее!
📱 Tg | 💙 ВК | 💬 Max | 3 381 |
| 17 |  👩💻 Вайбкодинг для СА: создание приложения с помощью ИИ 🤖🧠
щё недавно системный аналитик описывал требования и передавал их разработчикам. Теперь с помощью вайбкодинга он может сам превратить идею и требования в работающее приложение.
Означает ли это, что граница между аналитиком и программистом постепенно исчезает? И станет ли умение создавать решения с помощью ИИ новым обязательным навыком аналитика?
В этом выпуске проверяем возможности вайбкодинга на реальном кейсе.
🔗 Сайт эпизода
🔗 Приложение: инструмент для БД и SQL
Видео с демо (рекомендуется):
⏯ YouTube
⏯ RuTube
⏯ VK Video
⏯ Telegram
Аудио:
⏯ Apple Podcast
⏯ Яндекс.Музыка
⏯ Castbox
⏯ Звук
⏯ Spotify
GetAnalyst — база знаний с нереальным количеством практики в открытом доступе 😍
📱 Tg | 💙 ВК | 💬 Max | 3 221 |
| 18 |  💎 Архитектура для СА: открыта предзапись, старт 15 сентября 💎
Вы уже уверенный Middle, Middle+ или Senior. Понимаете процессы, работаете с интеграциями и API.
Микросервисы в теории понятны.
Знаете, зачем нужна Kafka.
Но как спроектировать реальный асинхронный процесс, в котором участвуют несколько сервисов?
🔴 Почему, например, остановка одного сервиса всё ещё блокирует процесс, несмотря на Kafka?
Потому что асинхронный обмен не отменяет зависимость между шагами. Если следующий шаг требует результата предыдущего, сообщение в брокере этот результат не заменит.
Нужно определить, где процесс может продолжаться независимо, где должен ждать и что произойдёт, если ожидание затянется.
От определения микросервисов и выбора технологий — к проектированию процессов между ними. На этом строится наш практический курс «Проектирование архитектуры» для системных аналитиков уровня уверенный Middle / Middle+ / Senior.
👉 Посмотреть программу
Что будем делать
▫️ Проектировать архитектуру с нуля: выбирать между монолитом, сервисной и микросервисной архитектурой.
▫️ Описывать архитектуру упрощенными схемами и с помощью нотации C4, чтобы обсуждать решения с командой.
▫️ Выбирать способы взаимодействия: REST, GraphQL, WebSocket и другие.
▫️ Проектировать асинхронные взаимодействия с Kafka и RabbitMQ, работать с вебхуками и описывать требования для разработчиков.
После практики с нами
✔️ Приходите на архитектурный митинг и ведёте его, а не просто участвуете.
✔️ Обосновываете повышение грейда конкретными навыками.
✔️ Проходите технические собеседования и сами выбираете оффер.
✔️ Переходите из проектной разработки в продукт с SOA или микросервисами.
✔️ Закрываете пробелы, которые давно хотели закрыть, и собираете своё публичное портфолио.
Процесс
12 онлайн-практикумов и теоретические модули в записи: разбираем демонстрационный проект и применяем подходы на дополнительном проекте для закрепления навыков.
✅ Домашние задания и обратная связь — на всех тарифах. Глубина проверки зависит от тарифа.
💎 Проектирование архитектуры
🗓 Старт 15 сентября
Предзапись до 11 сентября
🎁 скидка + мини-курс «Интеграции 4.0 — продвинутый уровень» в подарок
👉 Посмотреть программу и записаться | 3 189 |
| 19 |  +8🧩 7 архитектурных решений, которые аналитик принимает раньше архитектора
«Пользователь заказал товар, курьер загрузил посылку в постамат, пользователь её забрал».
Один процесс. Но сколько вопросов появляется, когда начинаешь его проектировать:
▫️ какие микросервисы нужны
▫️ где хранить данные об отправлениях, ячейках и оплатах
▫️ какие API использовать
▫️ где ждать ответ, а где передавать событие через брокер
▫️ кто вообще имеет право открыть ячейку
И это вопросы, с которыми системный аналитик сталкивается уже при проработке требований — ещё до готовой схемы архитектуры.
Конечно, архитектурные решения принимаются вместе с архитектором и разработчиками.
👉 Но аналитику важно понимать, что именно мы выбираем и как этот выбор влияет на работу системы.
В карточках разбираем 7 таких решений на примере проекта #PostamatGA. Без попытки поставить Kafka между всеми прямоугольниками 😃
📌 Сохраните последнюю карточку — пригодится при обсуждении следующей большой фичи или нового проекта.
#АрхитектураGA
📱 Tg | 💙 ВК | 💬 Max | 3 702 |
| 20 |  +3🔵🔥 Нотация 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 в Mir
🔖Это максимально полный гайд по C4.
Сохраняйте, чтобы теория, примеры и практика по C4 были под рукой, когда понадобится спроектировать архитектуру.
#АрхитектураGA
📱 Tg | 💙 ВК | 💬 Max | 3 242 |
