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

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

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

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

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

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 марта.
Успевайте записаться!

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

Наш курс — про БАЗУ, которая нужна джунам, мидлам и даже сеньорам! 🚀

К нам приходят как новички в IT, так и те, кто уже работает 1—3 года системным аналитиком.
Сложно качественно и уверенно выполнять свою работу, когда не владеешь базой. Но хорошая новость — это быстро исправляется!

🔹 У нас индивидуальный подход к каждому, и для каждого отличается уровень сложности.
🔹 Прокачиваем то, что нужно ученику здесь и сейчас.
Задания варьируются и адаптируются под уровень знаний каждого!
🔹 Такой подход возможен только на небольших потоках.

С какими запросами приходят наши ученики?
💼 «Хочу сменить работу» — но не хватает знаний для работы в другой компании, был ограниченный круг задач, а на рынке требуют большего.
📊 «Дали задачу по проектированию БД» — но я никогда этого не делал.
📄 «Поручили составить документацию» — а как её начать делать и как оформлять, непонятно.
🎓 «На проекте я единственный системный аналитик» — и не у кого спросить best practice.

Если вы узнали себя — мы готовы помочь.
Мы работаем лично с каждым и доводим до результата. Приходите на поток курса Системный аналитик.БАЗА. Успевайте!

😱 Страх 2. Мне дали задачу, которую я никогда не делал(а). ЧТО ДЕЛАТЬ??

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

Скажите своему продакту или тимлиду, что у вас есть трудности.
Они отвечают за результат команды и сроки, поэтому заинтересованы в том, чтобы задача была выполнена. Им самим не нужны простои, так что они сделают всё, чтобы помочь вам:
🔹 Подскажут, куда копать.
🔹 Найдут нужного человека.
🔹 Дадут документацию или помогут разобраться сами.

Так что не стесняйтесь задавать вопросы и просить помощи.

Что делать, если задача незнакомая?
1️⃣ Не бойтесь сказать, что вам нужна доп. информация. Никто не ожидает, что вы экстрасенс и сразу всё знаете.
2️⃣ Разбейте задачу на части. Разделите её на понятные шаги и начните с тех, в которых уверены.
3️⃣ Подключите коллег. Если есть наставник, тимлид или опытный аналитик — спросите, как он бы подошёл к этой задаче.
4️⃣ Используйте документацию и наработки. Возможно, похожая задача уже решалась. Посмотрите Confluence, Jira, старые ТЗ, переписки в чатах.
5️⃣ Запрашивайте ревью. Прежде чем двигаться дальше, уточните, правильно ли вы поняли суть задачи.

💡 Помните, если вам дали незнакомую задачу — значит, вам доверяют! Это возможность прокачаться и научиться новому. Главное — не бояться спрашивать, искать информацию и делать шаги вперёд. 🚀

❓Были ли у вас такие ситуации? Как справлялись?
Делитесь в комментариях! 👇

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

Всем привет! 👋
С вами Вера, основатель AnalystCore.

Сегодня я просто хочу поделиться фразой, которой руководствуюсь в работе:

Лицо системного аналитика — это его документация, продукт его работы

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

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

Немного рекомендаций по ведению документации:

1️⃣ Убирайте дублирование. Если одно и то же описание повторяется в нескольких местах, его легко забыть обновить везде и документация «разъедется».
2️⃣ Делайте перекрёстные ссылки. Документация должна читаться, как Википедия, где вы переходите по ссылкам.
3️⃣ Описывайте ровно столько, сколько нужно вашей команде и вашему проекту. Ни больше, ни меньше.
4️⃣ Не рисуйте схему ради схемы. Визуализация должна помогать, а не усложнять.
5️⃣ У документации, как и у любого продукта, есть свои пользователи — менеджеры, разработчики, тестировщики, смежники. Спросите их, что они хотят найти в документации.

Так документация будет приносить пользу, а её актуальность будет проще поддерживать.

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

За 8+ лет опыта я была на 15+ проектах и видела разную документацию — хорошую, плохую, очень плохую. За это время я сформировала best practices, которые делают документацию понятной, красивой, читаемой и такой, за которую не стыдно.

Хочу закончить пост своей любимой мыслью:

Давайте работать так, чтобы было не стыдно.
Не стыдно за свою работу. Не стыдно за свою документацию. 💪

#sa_dev

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

Мы активно дорабатываем наш сайт и платформу. 🙂 На выходных зарелизили изменения:
- Начали вести главную страницу.
- Выкатили новый раздел «База знаний». Там будут статьи по животрепещущим вопросам системных аналитиков.
- Доработали архитектуру, поправили баги.

Сегодня просто хочется сказать спасибо, что вы с нами ❤️. Нам очень приятно, когда вы пишете в ЛС и что-то спрашиваете. Когда вы ставите реакции и пишете комментарии, мы понимаем, что всё это не зря и мы делаем действительно важное дело.

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

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

❌ Внимание! Набор на поток 14 марта закрыт

Места на курс «Системный аналитик. БАЗА» закончились!

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

✨ Этот поток собрал большой ажиотаж, и все места уже заняты.
Тем, кто долго сомневался — в следующий раз действуйте быстрее! 😉

Что делать, если не успели?
1️⃣ Ждите анонсов новых потоков.
2️⃣ Доступен тариф «Только послушать» 🎧 — можно изучать материалы уже сейчас, а затем перейти на тариф с практикой, чатом, доп. темами в новом потоке.

Спасибо за доверие! Будем рады видеть вас в следующих запусках. 💙

Задача с собеседования: разрабатываем Use Cases для лифта 🚀

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

📌 Основной сценарий:

Пользователь заходит в лифт, выбирает этаж и едет.

Но реальность сложнее! Какие есть альтернативные сценарии и расширения?
Продумываем все возможные кейсы, включая неожиданные ситуации:

🔹 Что если лифт перегружен?
🔹 Что если не работает кнопка вызова?
🔹 А если пассажир передумал и хочет сменить этаж?
🔹 Как быть, если лифт застрял?
🔹 А что если лифт движется без пассажиров?
🔹 Не забываем про необычные Use Case — например, посмотреться в зеркало!

❓ Как бы вы ответили на собеседовании?
Выберите все варианты, которые можно оформить в отдельный Use Case, альтернативный сценарий или расширение.

👇👇👇👇👇

В следующем посте разберём ответы.

#interview

Разбираем Use Case для лифта: какие сценарии учесть? 🚀

В прошлом посте мы предложили вам проанализировать сценарии взаимодействия с лифтом. Давайте разберем ответы:

📌 Основной сценарий:

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

⚡ Расширения:
(по распространенному шаблону Use Case в этом пункте пишем и альтернативы, и расширения. Но можно и разнести их на отдельные пункты)

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

✅ Лифт перегружен, система блокирует двери.
Если лифт перегружен, двери не закроются, и пассажиры должны выйти.

✅ Лифт застрял, пассажир нажимает кнопку тревоги.
Система должна оповестить диспетчера и уведомить пассажира о вызове помощи.

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

✅ Лифт едет, но в кабине никого нет.
Лифт может возвращаться на дефолтный этаж или оставаться там, где его последний раз использовали.

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

🤔 Сценарии, которые выглядят фантастично, но могут быть интересны в будущем:

❌ Лифт телепортируется на нужный этаж.
На данный момент технология невозможна, но представьте, если бы была! 😃

❌ Лифт сканирует личность пассажира и автоматически едет на его этаж.
Теоретически возможно при интеграции с биометрией или ID-картами. Например, в бизнес-центрах такая функция может быть востребована.

Когда мы прорабатываем Use Case, нам важно учитывать не только основной сценарий, но и альтернативны (что может пойти не так или дополнительные возможности).

В реальных проектах именно проработка таких деталей отличает хорошего аналитика от новичка.

📢 А уже через пару дней мы сделаем важный анонс, связанный с Use Case! Следите за каналом.

#interview

📢 Анонс курса!
Мы запустили курс по User Story и Use Case! 🔥

Если вы хотите научиться писать понятные, полезные и действительно работающие User Story и Use Case, этот курс для вас. Мы разберём, как их правильно использовать, чтобы команда вас понимала с полуслова, задачи не превращались в хаос, а документация работала на вас, а не против.

🔹 User Story — это не просто формулировка «Я, как пользователь…»! Это методика, которая помогает команде лучше понимать задачи, расставлять приоритеты и эффективно развивать продукт.
🔹 Use Case — это инструмент, который поможет вам детально анализировать функциональность, учитывать альтернативные сценарии и вести документацию без лишнего дублирования.

ДЛЯ КОГО ЭТОТ КУРС?

Если вы уже работаете системным аналитиком, бизнес-аналитиком, менеджером продукта, тестировщиком или разработчиком, но хотите лучше разбираться в User Story и Use Case, понимать их тонкости и использовать на практике — этот курс для вас.

ЧТО ВАС ЖДЁТ?

✅ Создавать User Story, которые реально помогают команде, а не просто заполняют бэклог.
✅ Работать с User Story по всем правилам, а не так, как это делают «для галочки».
✅ Грамотно анализировать требования с помощью Use Case, чтобы не терять важные детали.
✅ Находить и описывать альтернативные сценарии, продумывать исключения и расширения.
✅ Оформлять Use Case чётко и структурированно, без дублирования и хаоса в документации.

Если в вашем резюме есть строчка «Опыт работы с User Story и Use Case», но в душе есть сомнения «а правильно ли я их пишу? 😱» — этот курс точно поможет вам стать увереннее в себе.

🚀 Обучение стартует в любое время, но не откладывайте!
Сейчас действует специальная цена, но скоро стоимость повысится. Успейте вписаться!

🔗 Подробнее о курсе 👉 analystcore.com

User Story для галочки ✅

Во многих командах User Story пишут просто потому, что так предполагается по процессу.

Мы работаем по User Story, значит, на каждую задачу нужно написать историю.

Но если писать истории без смысла, это не помогает проекту — это просто формальность. 🤦‍♂️

Примеры плохих User Story:

❌ Я, как пользователь, хочу скачивать файлы, потому что хочу скачать файлы.
❌ Я, как пользователь, хочу видеть раздел «О компании», чтобы знать, что компания существует.
❌ Я, как пользователь, хочу, чтобы у кнопки «Купить» был зелёный цвет, чтобы она была заметной.
❌ Я, как система, хочу логировать все запросы к API, чтобы логи были.

С виду всё по шаблону, но такие истории не несут ценности, не помогают команде, а просто заполняют бэклог ради процесса.

Почему они плохие? ❌
Разберём в следующем посте... 👇

А пока, если хотите научиться писать реально работающие User Story, начните обучение с нашего бесплатного урока по формату User Story 🚀

#user_story

Немного внутрянки)
Забегайте в канал Веры, основателя AnalystCore 🎉