Система ↔️ Система

Нарисовали сиквенс-диаграмму на взаимодействие между двумя сервисами.

Кстати, этот пример демонстрирует, что не только «человек» инициирует какой-то процесс. В нашем примере процесс запускается автоматически, по триггеру — в 01:00.

Хотите нарисовать такую же схему?
Заходите на plantuml.com
Вставьте код👇

@startuml
actor TimeTrigger as «Триггер времени»
participant ReportService as «Сервис отчетности»
participant Kafka as «Kafka»
participant NotificationService as «Сервис уведомлений»

TimeTrigger -> ReportService: Наступило 01:00
ReportService -> ReportService: Генерирует отчет
ReportService -> Kafka: Публикует событие «Отчет готов»

NotificationService -> Kafka: Pull сообщения из топика
NotificationService -> NotificationService: Отправляет письмо, что отчет готов
@enduml

#uml #sequence #diagrams

Sequence Diagram: базовые элементы. Часть 1

Всем привет! 👋
По итогам опроса большинство выбрало разобрать элементы сиквенс-диаграммы в PlantUML. Начнём с основ — без них никуда:

1️⃣ Участники

Это всё, что взаимодействует в рамках процесса: пользователь (включая разные роли), микросервис, внешняя система, брокер и пр.
Если нужно визуально отделить участников (participant), используйте типы:
* actor
* boundary
* control
* entity
* database
* collections
* queue

Объявляем участников на PlantUML так:

participant Participant
actor Actor
boundary Boundary
control Control
entity Entity
database Database
collections Collections
queue Queue

2️⃣ Линии жизни
Они отображаются автоматически после объявления участника и показывают период, в течение которого объект «живёт» в процессе. Проще говоря, это визуализация начала и завершения активности объекта, чтобы было понятно, когда и как он участвует во взаимодействии.

3️⃣ Сообщения
Отображаются в виде стрелок, показывают, кто инициирует вызов, и кто отвечает:

User -> System: Запрос
System --> User: Ответ

Попробуйте прямо сейчас на plantuml.com: вставьте этот код и посмотрите, как всё визуализируется.

В следующих постах поговорим о ветвлениях (alt, opt), других полезных конструкциях и хорошем стиле.

#sequence #plantuml #diagrams

Когда открыл PlantUML и видишь, что всё пишется в виде кода:

💬 Да это же просто! Сейчас нарисую!
…через 10 минут…
🤔 А как там создать notebox? И где подключить стили? Кто-нибудь, спасите!

💡 Лайфхак: Начните с самых простых элементов из прошлого поста. А украшение диаграммы (note, цвет, стили) добавьте потом, когда логика на диаграмме будет выстроена правильно — ведь это самое главное.

#plantuml #sequence #diagrams

Sequence Diagram: ветвления и циклы. Часть 2

Всем привет! 👋
Продолжаем разбирать конструкции PlantUML, которые помогают точно описать логику взаимодействия. Сегодня расскажем, когда применять alt, opt и loop на практике.

1️⃣ alt — альтернативные сценарии
Блок alt используется, чтобы показать разные варианты развития событий. Например, при обработке HTTP-запроса можно явно указать, как реагировать на успешный и неудачный ответ:

Service_A -> Service_B: Отправить запрос
alt HTTP 200 OK
Service_B --> Service_A: Данные
else HTTP 500 Internal Server Error
Service_B --> Service_A: Сообщение об ошибке
end

Такой блок позволяет визуально отделить «успешный сценарий» от альтернативных.

2️⃣ opt — опциональные действия
Опциональные шаги выполняются только при соблюдении условия. Например, при авторизации, если включена двухфакторная аутентификация, система отправляет дополнительный код в SMS:

Front -> Back: Запрос авторизации
alt Успешная авторизация
Back --> Front: Токен
opt Если включена 2FA
Back -> SMS_Service: Отправить код подтверждения
end
else Неуспешная авторизация
Back --> Front: Ошибка
end

Здесь блок opt выполняется только если у пользователя активирована двухфакторная аутентификация.

3️⃣ loop — повторяющиеся действия
Цикл loop применяется, когда действие нужно повторить несколько раз. Например, попытка получения данных при временной недоступности сервиса:

loop Повторить до 3 раз, пока не получен ответ
Front -> Back: Запрос данных
alt Получен ответ
Back --> Front: Данные
else Нет ответа
Back --> Logger: Логирование ошибки
end
end

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

Попробуйте применить эти конструкции на plantuml.com.

#sequence #plantuml #diagrams

Sequence Diagram: красивое оформление (бантики 🎀). Часть 3

Продолжаем разбираться с PlantUML. Сегодня посмотрим фишки, которые делают диаграммы ещё нагляднее:

1️⃣ Нумерация сообщений
autonumber
Чтобы не прописывать номера шагов вручную, используйте ключевое слово autonumber. Оно автоматически пронумерует все сообщения, что удобно при изменениях в диаграмме.
Пример:

@startuml
autonumber
User -> System: Запрос данных
System --> User: Ответ
@enduml

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

2️⃣ Перенос текста
Если шаг слишком длинный, используйте \n для переноса строки и улучшения читаемости.
Пример:

User -> System: Запрос на получение\nданных о пользователе

3️⃣ Примечания
Добавляйте поясняющие примечания, чтобы выделить важные детали или уточнить логику.
Пример:

@startuml
autonumber
User -> System: Запрос данных
note right of User: Какое-то примечание
System --> User: Ответ
@enduml

Попробуйте применить эти возможности в своих диаграммах на plantuml.com — они помогут сделать описание процессов ещё понятнее!

#sequence #plantuml #diagrams

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

Системный аналитик — это про интеграции, БД, REST API и кафку.

❓ Что думаете? Напишите своё мнение в комментариях
👇👇👇👇👇

Суббота — самое время повторить изученное! За последние две недели мы много говорили о Sequence Diagram. Давайте освежим в памяти, как с помощью этой диаграммы можно показать взаимодействие между:

✅ Пользователь ↔️ Система
✅ Фронтенд ↔️ Бэкенд
✅ Система ↔️ Внешние API
✅ Система ↔️ Система

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

Мы разобрали в трёх частях полезные элементы PlantUML. Переходите к постам, копируйте код и смотрите, как он отрендерится на plantuml.com.

🔗 Sequence Diagram — полезные элементы:
📌 Часть 1
📌 Часть 2
📌 Часть 3 про бантики на диаграмме 🎀

Хороших выходных!

С вами Вера и Юрий,
Основатели AnalystCore

Что происходит после нажатия на кнопку «Войти»? 🤔

Недавно на собеседовании мы обсуждали диаграммы и процессы, и мне задали интересный вопрос:

💬 «Расскажите последовательно, что происходит после нажатия на кнопку Войти?»

❓ Цель такого вопроса — проверить, насколько глубоко кандидат понимает процессы. Мыслите ли вы только на уровне фронта? Или заглядываете в бэкенд? Понимаете ли архитектуру, безопасность, работу сессий, что там с паролями?

🔍 Разобрали бы несколько таких задач и вопросов, которые реально встречаются на интервью?
Голосуйте в опросе ниже
👇👇👇👇👇

#interview

Что происходит после нажатия на кнопку «Войти»? 🚀
Вопрос с собеседования

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

🔹 1. Действия на фронтенде
* Пользователь вводит логин/пароль и нажимает «Войти».
* Фронтенд собирает данные и отправляет запрос на сервер (POST /auth/login).
* Возможна валидация данных на клиенте (например, проверка длины пароля, формата email).

🔹 2. Валидация и обработка на сервере
* Бэкенд принимает запрос и проверяет его структуру (JSON, параметры, корректность полей).
* Проходит валидация логина и пароля (например, проверка длины, запрещённые символы).
* Сервер запрашивает данные пользователя из БД.

🔹 3. Проверка учётных данных
* Бэкенд сравнивает введённый пароль с захешированным паролем в БД.
* Если пароль совпадает → успешная авторизация.
* Если нет → сервер отправляет ошибку (401 Unauthorized).

🔹 4. Генерация токенов и управление сессией
* Сервер генерирует JWT-токен / session ID для аутентифицированного пользователя.
* В некоторых случаях сервер может обновить refresh-токен, если используется OAuth.
* Информация о сессии может быть записана в кеш (Redis) или БД.

🔹 5. Ответ от сервера и обработка на фронте
* Сервер отправляет ответ с access-токеном и данными пользователя.
* Фронтенд получает токен и сохраняет его (например, в localStorage или cookies).
* Пользователь перенаправляется на главную страницу.

🔹 6. Дополнительные механики
* Если включена двухфакторная аутентификация (2FA) → сервер требует дополнительного подтверждения.
* Если несколько неудачных попыток входа → аккаунт может быть заблокирован или требуется капча.
* Если логин с нового устройства → система может запросить подтверждение через почту/SMS.

На что смотрит интервьюер?
✔️ Глубина мышления — ограничиваетесь ли только фронтом или понимаете, что происходит дальше?
✔️ Знание архитектуры — умеете ли объяснить кеширование, работу токенов?
✔️ Безопасность — знаете ли про хранение паролей, OAuth 2.0, сессии?

Вот так один простой вопрос может показать, насколько вы разбираетесь в процессе!

#interview

Задача с собеседования: продумываем доработку 🚀

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

📌 Задача:
Есть клиенты, которые давно не делали заказ. Нужно, чтобы система отправляла им уведомление, мотивируя вернуться.

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

В ходе этого «расследования» вы можете выйти на то, что:
🔍 Нужен сервис уведомлений, потому что его нет.
🔍 Придётся разрабатывать админку для маркетологов, чтобы они могли настраивать сегменты клиентов и тексты сообщений.
🔍 Вопросы интеграции: с чем и как будет взаимодействовать система?

❓ Как бы вы проанализировали и спроектировали это задание на собеседовании? 🤔
Пишите свои мысли в комментариях!
👇👇👇👇👇

#interview

Вопросы с собеседований: синхронное или асинхронное взаимодействие? 🤔

На собеседованиях системным аналитикам часто дают практические задачи: определить, какое взаимодействие здесь уместно — синхронное или асинхронное?

🔹 Синхронное взаимодействие — когда один сервис ждёт ответа от другого перед выполнением следующих шагов. Если ответа нет, процесс приостанавливается.
Пример: Пользователь запрашивает баланс на сайте банка → фронтенд ждёт ответ от сервера, прежде чем показать сумму.

🔹 Асинхронное взаимодействие — когда сервис не ждёт ответа и продолжает работать. Ответ может прийти позже, когда данные будут готовы.
Пример: Пользователь сделал заказ → магазин отправляет запрос на доставку → заказ оформлен, а информация о доставке поступит отдельно.

❓Определите, какое взаимодействие можно сделать в этих случаях:

1️⃣ Мастер-система владеет справочником оргструктуры. Другие сервисы используют его данные.
➡️ Синхронное или асинхронное взаимодействие?

2️⃣ Есть курсы валют, сервису они нужны. Как их получать?
➡️ Синхронное или асинхронное?

3️⃣ Покупка/продажа акций.
➡️ Синхронное или асинхронное?

4️⃣ Купил билеты в кино → сервис отправки писем должен отправить письмо.
➡️ Синхронное или асинхронное?

5️⃣ Проверка наличия товара в магазине при оформлении заказа.
➡️ Синхронное или асинхронное?

📌 Какой вариант выбрали бы вы?
Пишите в комментариях, разберём в следующем посте!
👇👇👇👇👇

#interview

Разбираем задачу 🤔: синхронное или асинхронное взаимодействие? ЧАСТЬ 1.

1️⃣ Мастер-система владеет справочником оргструктуры. Другие сервисы используют его данные.
➡️ Асинхронное
🔹 Данные в справочнике меняются не мгновенно. Если каждый сервис будет запрашивать их синхронно перед каждым использованием, это создаст лишнюю нагрузку на мастер-систему.

Как сделать?
* Мастер-система может пушить изменения в другие сервисы через Kafka/RabbitMQ.
* Либо другие системы могут периодически обновлять справочник (например, раз в 24 часа).

Почему не синхронное?
❌ Если перед каждым действием сервису нужно ждать ответ от мастер-системы, он будет работать медленнее и может зависнуть, если мастер-система недоступна.
❌ При высокой нагрузке (например, много пользователей одновременно запрашивают данные) система может просто не выдержать.

👇👇👇👇👇

2️⃣ Есть курсы валют, сервису они нужны. Как их получать?
➡️ Асинхронное
🔹 Курсы валют не меняются каждую секунду, а значит нет смысла запрашивать их в реальном времени. Обычно обновления приходят раз в несколько минут или часов.

Как сделать?
* Обновлять курсы валют через периодический запрос (polling).
* Либо получать события о смене курса через брокер сообщений.
* Хранить курсы в кеше или в БД, чтобы сервисы не запрашивали их каждый раз.

Почему не синхронное?
❌ Если каждый сервис будет делать HTTP-запрос при каждом расчёте, это создаст избыточную нагрузку.
❌ Если API курсов недоступно, система зависнет или не сможет корректно выполнить расчёты.

📌 Когда синхронное всё же нужно?
Если речь идёт о торговле валютами в реальном времени, где важен курс на момент сделки — синхронный запрос может быть оправдан.

👇👇👇👇👇

3️⃣ Покупка/продажа акций.
➡️ Синхронное
🔹 Цена акций меняется каждую секунду. Пользователь должен получить подтверждение сделки сразу, иначе цена может измениться.

Как сделать?
* При отправке запроса сервис брокера фиксирует цену и даёт мгновенный ответ.
* Запрос выполняется транзакционно — если что-то пошло не так, откатываем операцию.

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

📌 Когда асинхронное всё же возможно?
Если пользователь делает отложенную заявку (например, «купить акцию, если цена упадёт ниже 100$»), тогда логика может быть асинхронной.

Продолжение следует...

#interview

Разбираем задачу 🤔: синхронное или асинхронное взаимодействие? ЧАСТЬ 2.

4️⃣ Купил билеты в кино → сервис отправки писем должен отправить письмо.
➡️ Асинхронное
🔹 Покупка билетов должна быть независимой от отправки письма. Даже если письмо не отправилось, билеты всё равно должны быть куплены.

Как сделать?
* Сервис покупки ставит задачу в очередь на отправку письма.
* Сервис уведомлений обрабатывает очередь и отправляет письма в фоновом режиме.

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

📌 Когда синхронное всё же возможно?
Если, например, перед покупкой требуется подтверждение через email/SMS (например, двухфакторная аутентификация), тогда синхронный запрос может быть оправдан.

👇👇👇👇👇

5️⃣ Проверка наличия товара в магазине при оформлении заказа.
➡️ Синхронное
🔹 Пользователь должен сразу знать, можно ли купить товар, а не ждать обновления информации.

Как сделать?
* Перед подтверждением заказа система делает запрос в складскую систему.
* Если товар есть — заказ подтверждается, если нет — выводится ошибка.

Почему не асинхронное?
❌ Если проверка будет асинхронной, пользователь сможет оформить заказ на несуществующий товар.
❌ Если складская система не отвечает, заказ повиснет в неопределённом статусе.

📌 Когда асинхронное всё же возможно?
Если магазин работает по предзаказу (например, товар можно заказать, даже если его нет в наличии), тогда можно оформить заказ, а проверку сделать позже.

👇👇👇👇👇

Вывод
Как видно, выбор синхронного или асинхронного взаимодействия зависит от:
🔹 Требований к скорости отклика — нужен мгновенный ответ или можно подождать?
🔹 Риск-факторов — если сервис недоступен, что произойдёт?
🔹 Нагрузки на систему — сколько запросов в секунду ожидается?

#interview

📣 Внимание! Сегодня стартует запись на новый поток курса «Системный аналитик.БАЗА»

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

Что вас ждёт?
⛰️ Актуальная программа и навыки на 2025 год, которые нужны работодателям
⛰️ 8 заданий, проверяемых экспертом. На выходе документация для вашего портфолио
⛰️ Через 4 месяца сможете начать искать работу и проходить собеседования
⛰️ Помощь с трудоустройством: проверим ваше резюме и проведём тестовый собес 💪

Как проходит обучение?
1️⃣ Получаете доступ и начинаете смотреть видеоуроки
2️⃣ Будете заниматься сами, но не в одиночестве. Вас добавляют в чат потока с поддержкой от авторов курса
4️⃣ Получаете сертификат
5️⃣ Готовитесь к трудоустройству
6️⃣ Ищете работу с поддержкой экспертов

Поток стартует 14 марта, а количество мест очень ограничено — не упустите свой шанс стать уверенными системными аналитиками как можно скорее.

За подробностями 👉 analystcore.com

Успейте занять место!

Задача с собеседования: спроектируйте взаимодействие 🔍

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

Как организовать взаимодействие, чтобы система была надёжной и масштабируемой?
Возможные решения:

1️⃣ Синхронный вариант
Как работает:
Читающие сервисы сами запрашивают данные у основного сервиса (API, БД).
Данные обновляются по запросу, когда потребителю это нужно.

Плюсы/минусы:
✅ Простая реализация через REST API или GraphQL.
✅ Каждый сервис сам решает, когда обновлять данные.
❌ Четыре сервиса нагружают основной сервис запросами.
❌ Если один сервис запрашивает данные раз в час, а другой — раз в секунду, их версии могут отличаться.

Когда подходит?
✔️ Если данные меняются редко и можно получать их по требованию.

2️⃣ Асинхронный вариант
Как работает:
Основной сервис отправляет данные сам через брокер сообщений (Kafka, RabbitMQ).
Читающие сервисы подписаны на события и получают данные, как только они появляются.

Плюсы/минусы:
✅ Основной сервис не перегружается — данные не запрашиваются лишний раз.
✅ Все подписчики получают обновления в реальном времени.
✅ Если один из сервисов временно недоступен, он получит данные позже.
❌ Требует настройку брокера сообщений и подписок.
❌ Нужно контролировать, обработал ли сервис сообщение или потерял.

Когда подходит?
✔️ Если данные обновляются часто, и важно передавать их мгновенно.
✔️ Если подписчиков много, и мы не хотим перегружать основной сервис.

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

#interview

Объявляем рубрику страхов! 🙀

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

😱 Страх 1. Я боюсь читать мессенджер — вдруг там вопрос, на который я не смогу ответить.
А если ваш наставник ушёл в отпуск или старший коллега по цеху недоступен — вообще кошмар.

Правда в том, что системным аналитикам пишут постоянно. Это члены команды, заказчики, коллеги из других отделов. Смежники часто задают вопросы:
❓ А если мы добавим новое поле в API, у вас ничего не сломается?
❓ Вы используете наш метод? Мы его хотим выпилить.
❓ На что влияет ваш справочник? Как другие системы его используют?
❓ Вы в коде готовы к такой-то ошибке от нас? Мы её немного изменили, надеемся, вас не задело.
❓ Если мы пришлём вам в этом параметре N/A, что будет?

Вначале реакция стандартная, и её не нужно стыдиться:
😱 Откуда я знаю? Я на этом проекте всего полгода!
😱 Откуда мне знать, что в коде у разработчиков?
😱 Опять придётся лезть в код, а я там ничего не понимаю…
😱 О нет… Придётся отвлекать разработчиков. Как бы перебороть это чувство и всё-таки написать?..
😱 Но я же не отвечаю за то, как наши справочники используют другие системы. Я правда должен это знать?

Любая из этих реакций — нормальная. Вы не одиноки!

Главное — не позволяйте этому подорвать вашу уверенность:
1️⃣ Вы не обязаны отвечать сразу. Этот вопрос вообще-то отвлёк вас от рабочих задач. Выделяйте отдельное время в день на такие вопросы.
2️⃣ Не бойтесь сказать, что вам нужно время на поиск ответа. Вы не можете знать всё. И ответ не ожидают только от вас. Вы — это входная точка в команду. Подключайте коллег.
3️⃣ Да, вам снова придётся идти к разработчикам. Это нормально. У вас Confluence, у них код. Вы отвечаете за разные вещи.
4️⃣ С каждым таким вопросом вы лучше узнаёте систему. Через несколько месяцев сможете отвечать сразу, без доп. исследований.

ЭТОТ СТРАХ МОЖНО СНИЗИТЬ 👇
Первый шаг — вести документацию 📄. Если там будет описано всё важное, походы по отделам сократятся в разы.

📌 На курсе «Системный аналитик. БАЗА» результат — написанная документация.
Вы сможете задавать вопросы по вашему проекту, а мы поможем и подскажем, как лучше организовать доку в вашем случае.

✨ Старт потока — 14 марта.
Успевайте записаться!

#страхинаработе