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

🌱 Одна из ступеней профессионального роста системного аналитика - работа в тесном сотрудничестве с архитекторами на проектах с сервисной или микросервисной архитектурой.

Мы в GetAnalyst создали программу для опытных специалистов, которая помогает на практике получить все нужные знания по архитектуре, чтобы продолжать расти в карьере и соответствовать актуальным требованиям компаний:


⚡ Проектирование архитектуры
🗓 Старт: 3 июня 2025
👉 Подробности и заявка на участие


🎁 Сегодня последний день, когда открыта запись на самых выгодных условиях:
✔️ спец. цена
✔️ дополнительное обучение по REST API в подарок


По всем вопросам пишите @getanalyst, info@getanalyst.ru или оставляйте заявку через сайт. Мы свяжемся с вами, поможем оценить текущие навыки и ответим на ваши вопросы 🤝

Благодарности пост 🩷

Каждое сообщение от вас вызывает восторг.
Греет и вдохновляет делать ещё лучше.

Мы гордимся каждым, кто с нами! И всегда стараемся дать вам больше.

Спасибо, что замечаете.
Это очень много значит.

Все ваши тёплые слова — знак, что всё не зря 🩷

P.S. Мне кажется я в последние годы сама ещё чаще начала писать слова благодарности тем, кто помогает мне быть лучше. Бесконечный обмен положительной энергией 🙂

🔹 C4/Context - пример архитектуры для проекта #GreenChargeGA 🔹

Уровень Context в нотации C4 нужен, чтобы дать высокоуровневое представление о системе и ее окружении.

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

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

👉 Что нужно показывать?

🔹 Основную систему – объект проектирования (например, интернет-магазин, банковское приложение).

🔹 Пользователей – кто взаимодействует с системой (клиенты, администраторы, партнеры).

🔹 Внешние системы – с чем интегрируется (платежные сервисы, справочники, ЭДО и другие).

🔹 Типы взаимодействий – основные потоки данных (например, клиент отправляет заказ в систему, система взаимодействует с банком).


👉 Что важно знать?

На этом уровне НЕ важно, какая архитектура будет использована – монолит, микросервисы, сервисы.

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

Это первый шаг проектирования архитектуры – помогает всем участникам проекта построить общее понимание системы.


👉 Пример для системы зарядки электромобилей - проект #GreenChargeGA

✔️ Основная система:
GreenChargeGA

✔️ Пользователи:
пользователи, которым нужно заряжать авто
сотрудники тех поддержки,
администраторы

✔️ Внешние системы:
ТБанк Интернет-эквайринг,
ТБанк Торговый эквайринг,
POS-Терминал для приема карт,
сканер QR-кодов,
датчики зарядной станции (энергия, температура и тп)
firebase (push)
unisender (sms/email)


Ни API, ни микросервисов, ни брокеров. Всё на верхнем уровне, чтобы осознать интеграции системы и пользователей. Ни более.
Сравните это со схемой проекта без нотации и увидите огромную разницу в количестве элементов!


Схема архитектуры в C4/Context прикреплена к посту 🙌


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

🔋 Схема микросервисной архитектуры - разбор проекта #GreenChargeGA 🔋

Вы уже знаете:
✔️ что такое микросервисы
✔️ как выделяют микросервисы
✔️ API Gateway
✔️ шаблоны проектирования микросервисов

Применим знания на практике и выделим микросервисы для системы зарядок электромобилей👇


⚙️ Управление пользователями
Регистрация аккаунтов владельцей электро-авто, подтверждение учетных записей по SMS, редактирование профилей.
Принцип:
+ независимая сущность
+ высокая нагрузка
+ DDD


⚙️ Программа лояльности
Бонусные карты пользователей, расчет кэшбека за оплату и начисление бонусов, для использования в счет оплаты будущих зарядок.
Принцип:
+ группа логически связанных функций
+ высокая нагрузка из-за связанных оплат
+ DDD


⚙️ Зарядные станции
Регистрация зарядных станций, настройка данных о них, получение информации о состоянии станции, отображение на карте, обновление цен на зарядку.
Принцип:
как пользователи.


⚙️ Управление ценами
Гибкая настройка цен для разных локаций, времён суток, динамическое ценообразование.
Принцип:
как пользователи.


⚙️ Контроль зарядки
Старт и остановка зарядки, расчёт времени и объёма потребления энергии, расчёт суммы к оплате.


⚙️ Платежи
Оплата зарядки - интеграция с платёжной системой для обработки банковских платежей картой, возвраты, генерация чеков. Авторизация карты на старте и автосписание средств по окончании зарядки.


⚙️ Очереди на зарядку
Бронирование места в очереди на станцию, управление ожиданием, снятие с очереди при неявке.


⚙️ Уведомления
Push-уведомления, email, SMS-уведомления.


⚙️ Тех. поддержка
Обработка чатов, передача обращений операторам, отображение в панели.


⚙️ Аналитика и отчеты
Отчёты о выручке, аналитика по станциям, загрузке, популярности, эффективности.


⚙️ Телеметрия
Сбор телеметрических данных с оборудования (энергия, температура и т.п.)


⚙️ API Gateway
Аутентификация запросов, кэш, и маршрутизация к соответствующим микросервисам.


+ API выберем,
+ с брокерами разберёмся 🤝


Схема прикреплена к посту ✅
Исследуем!

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

💥 Открытый урок по Архитектуре систем для аналитиков [31 мая - 2 июня] 💥

Представьте, что вы приходите на собеседование и спокойно говорите «нет». Или вежливо завершаете его в середине. Почему опытные аналитики так делают? Потому что снова предложили очередной скучный проект — работать с монолитом.

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

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


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

🚀 От монолита к микросервисам: пошаговый план с примером
🗓 Доступ 31 мая - 2 июня (сб - пн)
🔗 ЗАРЕГИСТРИРОВАТЬСЯ

Что ожидать от этого обучения:
🌟 Поймете основы проектирования архитектуры
🌟 Разберетесь в отличиях монолита, сервисов и микросервисов
🌟 Освоите чтение и создание схем архитектуры
🌟 Узнаете на практике, как происходит переезд с монолита на микросервисы
🌟 Получите готовые схемы и подходы по проектированию


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


Готовы получить новый опыт на практике?
Регистрируйтесь сейчас и смотрите урок в записи с 31 мая по 2 июня! 🙌

🔵 Моделирование архитектуры в нотации С4 🔵

Можешь показать схему архитектуры системы без нотации, в виде прямоугольников и стрелочек? Отлично! Первый шаг к пониманию работы системы сделан.

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

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

📚C4 - нотация моделирования архитектуры, которая упрощает визуализацию сложных систем.


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

👉 Контекст (C4 / Context) - система, её интеграции и пользователи.

👉 Контейнеры (C4 / Container) - независимые по коду приложения внутри системы, детализация главного прямоугольника c C4 / Context.

👉 Компоненты (C4 / Component) - модули кода и зависимости между ними, детализирует один из контейнеров с C4 / Container.

👉 Код (C4 / Code) - описывает реализацию кода для конкретных компонентов системы, детализирует C4 / Component.


Материалы для быстрого самостоятельного изучения C4:
🔗 Официальный сайт C4 (англ)
🔗 Шаблон с примером архитектуры в Miro
🔗 Нотация моделирования архитектуры С4 — примеры диаграмм и инструменты


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

🚨 Является ли API Gateway единой точкой отказа? 🚨

Мой любимый вопрос, который был задан в комментариях к посту про API Gateway 🙂
Его также часто задают на собеседованиях.

Ответ:

Да — если он не масштабирован горизонтально.

Если на сервере развернут единственный инстанс (установленная копия) API Gateway и он выйдет из строя, работа всех клиентов, которые в него обращаются, остановится.

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


🚨 Что будет, если API Gateway «упадёт»?
1. Внешние клиенты потеряют доступ к сервисам.
2. Внутренние вызовы (если они идут через Gateway) тоже могут быть нарушены.
3. В логах вы увидите HTTP 502 / 503 ошибки (Bad Gateway / Service Unavailable).
4. Мониторинг начнёт фиксировать обрыв соединения и рост ошибок. Это будет сложно не заметить 🥲


👉 Как это решается?
Чтобы API Gateway не стал "узким горлышком", применяют следующие решения:

🟢 Горизонтальное масштабирование
Несколько инстансов API Gateway, развернутых за балансировщиком нагрузки. Тогда при сбое одного — остальные продолжают обслуживать запросы.

🟢 Health-check и авто-рестарт
Kubernetes и другие оркестраторы позволяют перезапускать поды/контейнеры при сбое.

🟢 Failover-механизмы
Некоторые решения "из коробки" поддерживают автоматическое переключение между инстансами при сбоях.

🟢 Разделение входящего трафика
В больших системах могут использовать несколько API Gateway по зонам или типам трафика (например, публичный API и внутренний API)


Несмотря на сбой API Gateway, внутренние сервисы продолжают жить, поэтому, если они не делают обратные вызовы в API Gateway для обращения в другие сервисы, то все начатые цепочки транзакций (запросов) будут выполнены.

Т.е. данные не теряются, процессы продолжаются.

API Gateway - потенциальная точка отказа в системе?

👉 Да

Но при нормальной инфраструктуре не должен быть ею. Мы разбираем это на программе по архитектуре. Это часть про стык Инфраструктуры и Архитектуры, который важно осознавать аналитикам.

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

⚙️ 8 Шаблонов Проектирования Микросервисов ⚙️

1️⃣ API Gateway
Единая точка входа для всех внешних запросов.
Отвечает за маршрутизацию, кэширование, аутентификацию.
Подробнее

2️⃣ Service Registry and Discovery
Динамическое обнаружение и регистрация сервисов.
Это механизм? по которому сервисы сами находят адреса друг друга. Он помогает им корректно взаимодействовать без жёстко прописанных адресов.

3️⃣ Backends for Frontends (BFF)
Отдельные адаптивные бэкенды под каждый вид клиентов. Например: Web и Mobile.
Каждый клиент получает ровно те данные и в том виде, который ему нужен.

4️⃣ Event Driven
Микросервисы обмениваются информацией не напрямую, а через публикацию и подписку на «события» в общем брокере: один сервис публикует сообщение о случившемся изменении, а все заинтересованные сервисы, подписанные на эти события, асинхронно получают и обрабатывают их.

5️⃣ CQRS (Command Query Responsibility Segregation)
Шаблон, в котором операции изменения состояния системы (Commands) отделяются от операций чтения данных (Queries).
• Commands реализуют запись данных, с их валидацией.
• Queries оптимизированы под быстрое получение и агрегации, отчёты.

6️⃣ Database-per-Service
Изоляция данных каждого сервиса в своей БД.
Минимизирует зависимость между микросервисами.
Главная проблема - сложность синхронизации данных.

7️⃣ Оркестрация
Центральный сервис управляет порядком вызовов.
Обеспечивает:
• последовательность выполнения алгоритмов, которые используют разные микросервисы,
• целостность и контроль транзакций.
Пример сервиса-оркерстратора: Camunda.

8️⃣ Хореография
Сервисы обмениваются событиями напрямую через брокер, которые управляет порядком выполнения алгоримов, в которых задействованы разные микросервисы.


⚙️ Как применяют?
• В зависимости НФТ (нефункциональных требований).
• Часто комбинируют несколько подходов.


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


Исходник: png | svg (анимация)

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

🔔 Онлайн-практика по созданию БД с нуля сегодня | в 19:00 Мск 🔔

В GetAnalyst есть подписка на продвинутые практикумы по БД и SQL. И сегодня у нас стартует новая серия, с новым проектом.


Первое занятие:
📚 Проектирование БД с нуля: создание ER-диаграммы
🗓 19 Мая (пн), в 19:00 Мск

1. Определение БД и СУБД.
2. Знакомство с проектом и выделение сущностей.
3. Определение логической и физической моделей БД с разбором примеров по проекту.
4. Практика. Фокус на проектировании физической модели БД - PostgreSQL.
5. Обзор шаблона постановки задачи на разработчиков.

👉 Все подробности и запись


✅ Доступна запись занятия по AI для работы с БД и SQL.

🎁 Все, кто подключается к практикумам на 6 месяцев до 19 мая включительно, получат в подарок расширенный доступ к подписке - до 10.01.2026 (+2 месяца в подарок).
Так вам удастся посетить все 7 встреч по проекту 🙌


До встречи онлайн! 😊


Вопросы по подключению к этой серии продвинутых практикумов по БД и SQL можно задать через сайт, на почту info@getanalyst.ru или в ЛС @getanalyst.

🎂 GetAnalyst 4 года 🥳

4 года назад был куплен домен, запущен сайт, первый Telegram-чат, и я начала этот проект.

С первого года осталась табличка с полной подборкой каналов по СА и БА в Telegram. Их тогда было около 10.

Делала её, чтобы решить "почему я хочу делать GetAnalyst?" и "почему аналитики хотят сюда?".

Ответ был один:

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

В этом было и есть отличие.

Даже когда каналов уже не 10, а более 100.
И когда я наблюдаю на копирование проекта... 🥲 Но без того, что я в него вкладываю. Сердце, душу, время, и всегда самые новые и актуальные знания, которые сама постоянно добираю. Не по верхам, а в глубину, насколько возможно.


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

За эти годы мы вместе многому научились и выросли: появилось множество материалов, вебинаров и новых друзей.
Каждый ваш совет, каждый отзыв для нас бесценен — именно они помогают нам расти и становиться лучше ❤️


И, конечно, хочу поблагодарить всю команду GetAnalyst.
Спасибо вам за поддержку и веру в проект! 🙌

Спасибо, что вы с нами 🦭❤️

Екатерина Ананьева,
Основатель сообщества GetAnalyst
18 мая 2025

О проекте | Екатерина Ананьева

🪄 В потоке рабочих задач и домашних дел можно забивать заниматься саморазвитием.

То, что считалось новым и актуальным 5 лет назад, сегодня уже база, которую ты должен знать.

Знания устаревают быстрее, чем мы успеваем их освоить 🥲

А хочется всегда быть "в тренде" и лучшей версией себя.

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


👉 Учёба и саморазвитие – это топливо, которое двигает меня вперёд. В карьере, в жизни, в эмоциональном плане.
Поэтому каждый день я ищу возможность посвятить время обучению. Хотя бы 30-60 минут.

И это не всегда про техническое обучение. Я также периодически занимаюсь изучением тем по здоровью, психологии, инвестированию, маркетингу и не только.
Всем, что может помочь в жизни.


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

Особенно заряжают на учёбу встречи с разработчиками, с CEO и CTO компаний, у которых за плечами 20+ лет опыта и несколько стартапов в США.
После разговоров с ними будто включается внутренний мотор: хочется не просто знать больше, а сразу пробовать, применять, развиваться 🤩


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

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

И пусть этот рост приносит в нашу жизнь важные, настоящие и радостные перемены ❤️‍🔥📈🌱

🤖🔥 Model Context Protocol (MCP) — новые тренды AI для аналитиков 🔥🤖

YouTube | RuTube | VK

В видео:
🔹 Pet-проект с MCP: чат-бот, который интегрирован к Stripe, чтобы управлять онлайн-магазином
🔹 Сделано за 2 часа, без глубокого опыта разработки 😱
🔹 Делюсь идеями


MCP – это открытый протокол, введённый компанией Anthropic, который:
✅ стандартизирует способ обмена контекстом и данными
✅ между крупными языковыми моделями (LLM) и внешними системами (БД, API, сервисами и т.д.)

MCP даёт единый интерфейс для подключения AI (LLM моделей) к разным системам.


Как можно использовать MCP в разработке:
👉 LLM могут запрашивать необходимую информацию из внешних источников (БД, файлов, API) для обогащения своих ответов.
Например, теперь AI может самостоятельно сходить в вашу PosgreSQL, сделать нужных SQL в ней, и вернуть ответ на ваш вопрос, который вы задали в чате.

👉 MCP-сервер может вызывать команды! Вызывать реальные API-методы! Только ключ API и документацию ему дайте 🤯
Для создания заказа в CRM, отправки почты или SMS через систему рассылок, передачу документов в ЭДО или оплат в платёжной системе.

👉 MCP облегчает построение многошаговых workflow, когда одна команда приводит к цепочке действий. Можно заранее определить шаблоны задач (prompts) и последовательно вызывать нужные сервисы.


Почему MCP актуален:
🔥 Всё больше бизнес-процессов автоматизируется при помощи чат-ботов и AI-агентов.

🔥 Каждый новый LLM или сервис требует новых интеграций – их становится слишком много. MCP стандартизирует процесс интеграции. Вместо того чтобы каждый раз программировтаь новую интеграцию, достаточно использовать единый протокол MCP. Это ускоряет разработку в 100-ни раз!

🔥 С появлением инициатив по созданию более независимых AI-агентов (которые не только подсказывают, но и сами выполняют задачи) нужен новый уровень интеграции. MCP позиционируется как базовый слой для таких систем, позволяя ИИ-сервисам становиться «активными участниками» процессов.


Интеграции заиграли новыми красками с MCP 🌈

#AI_GetAnalyst

🧐 Зачем нужен API Gateway? 10 главных функций 👇

API Gateway (API-шлюз) — это единая точка входа для всех клиентских запросов к Backend.

Обычно используется в микросервисной архитектуре.

👉 Его главная функция — маршрутизация запросов.
Но, помимо этого, API Gateway предоставляет и другие важные функции.


Давайте последовательно разберём как он работает:

1️⃣ Первичная обработка запроса
Клиент отправляет запрос в API Gateway, а не напрямую к сервисам. Это обеспечивает централизованную точку входа в систему, а также упрощает интеграцию для клиента.

2️⃣ Валидация запроса
API Gateway проверяет корректность запроса.
Если формат нарушен — запрос отклоняется.

3️⃣ Проверка безопасности
Выполняется проверка по спискам разрешённых (allow-list) и запрещённых (deny-list) источников. Небезопасные запросы блокируются.

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

5️⃣ Ограничение частоты запросов (Rate Limiting)
Если клиент превышает лимит запросов — они отклоняются с соответствующим ответом.

6️⃣ Маршрутизация к нужному сервису
На основе пути или других признаков API-шлюз определяет, какому микросервису должен быть направлен запрос.

7️⃣ Преобразование протоколов
При необходимости, преобразует запрос в нужный формат.
Например, если API Gateway принимает запрос в HTTP (REST API), то он может преобразовать его в gRPC для внутреннего микросервиса.

8️⃣ Агрегация ответов
Если ответ зависит от нескольких микросервисов, API Gateway собирает данные с каждого и формирует единый ответ.

9️⃣ Возврат ответа клиенту
Сформированный ответ возвращается клиенту в нужном формате и в установленный тайм-ауты.

🔟 Логирование, мониторинг, обработка ошибок и кэширование
На протяжении всего процесса обработки запроса.


API Gateway упрощает взаимодействие клиентов с распределённой системой и обеспечивает её безопасную и управляемую работу, выступая в роли централизованной точки входа.

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

🛠 5 способов определения микросервисов 🛠

Микросервисы (МС) — это способ разбить большую систему на независимые, слабо связанные компоненты, каждый из которых отвечает за свою конкретную функцию и масштабируется отдельно.

Другими словами — это небольшие сервер-приложения с их собственными БД.

Ниже — примеры применения 5 ключевых подходов к декомпозиции сложной системы на микросервисы на примере проекта #GreenChargeGA по зарядке электромобилей.

-----------

1️⃣ По группам функций

Каждый МС объединяет логически связанные функции.

➕ Пользователи: регистрация, управление профилями пользователей
➕ Станции: управление зарядными станциями, их активностью, геолокацией для отражения на карте
➕ Бронирования: бронирование очереди на зарядку
➕ Биллинг: расчёт стоимости заправки, интеграция с платёжным провайдером, формирование чеков
➕ Уведомления: push/sms/email-уведомления о завершении заправки, подтверждении регистрации, коды для аутентификации
➕ Тех. поддержка: работа чат-ботов, обработка обращений пользователей

-----------

2️⃣ По доменам (DDD - Domain Driven Design)

Выделяем bounded contexts (ограниченные контексты) по предметным областям.

➕ Домен “Станции”
Управление статусом зарядки. Геолокация станций. Актуальные цены на зарядку.
➕ Домен “Пользователи”
Профили, регистрация, история сеансов.
➕ Домен “Платежи”
Интеграция с платежным провайдером, проведение платежей и формирование платежных документов, возвраты, отчеты о продажах.

-----------

3️⃣ По данным

Каждый МС управляет узким набором сущностей.

➕ Пользовательские сессии: аккаунты, авторизации, история входов
➕ Станции зарядки: локации, конфигурации, цены
➕ Сеансы зарядки: продолжительность, израсходованная энергия
➕ Платежи: чек, статус транзакции
➕ Обращения пользователей: запросы, ответы, статусы

-----------

4️⃣ По пользовательским сценариям

МС обслуживает конкретный Use Case.

➕ Поиск зарядной станции и бронирование места в очереди.
➕ Процесс зарядки: старт и авторизация банковской карты, обработка данных об израсходованной энергии и расчет итоговой стоимости, списание итоговой суммы за зарядку.
➕ Возврат средств.

-----------

5️⃣ По уровню нагрузки

Высоконагруженные и обычные части системы выделяются в отдельные сервисы со своими SLA и требованиями к масштабируемости.

➕ Поиск станции (много запросов по геолокации, особенно в «пиковые» часы).
➕ Сбор телеметрии (станция шлёт данные каждую 5 секунду, высокая частота).
➕ Обработка платежей (всплески нагрузки в моменты массовых зарядок).

-----------

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

👉 Сочетайте методы декомпозиции и подробно фиксируйте принципы выбора микросервисов в рамках проекта — это поможет избежать неясностей и обеспечит гибкость при развитии проекта.


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

⚡Архитектура для Системных Аналитиков: старт 3 июня ⚡

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


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

⚡ Проектирование архитектуры
🗓 Старт: 3 июня 2025
👉 Подробности и заявка на участие

В ходе работы мы будем:
✔️ Строить архитектуру проекта с нуля: монолит, сервисная, микросервисная.
✔️ Работать с нотацией C4.
✔️ Подбирать API для проекта и учиться работать с ними на практике: REST, GraphQL, WebSocket и другие.
✔️ Ставить задачи на брокеры (Kafka, RabbitMQ), Webhooks, и знакомиться с другими способами асинхронного взаимодействия систем.

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


Цели, которые ставят и реализуют наши аналитики в процессе обучения:
✅ Повышают грейд внутри компании
✅ Переходят из проектной разработки в продукт
✅ Структурируют знания и проходят аттестации
✅ Получают повышения
✅ Проходят собеседования и выбирают офферы по душе 🩷

Приглашаем и вас достигать новые цели вместе с нами с 3 июня 2025!

👉 Подробности и заявка на участие


🎁 До 26 мая открыта предзапись на специальных условиях:
скидка + дополнительное обучение по проектированию REST API в подарок.


Вопросы можно задать через сайт, на почту info@getanalyst.ru или в Telegram @getanalyst.