Как реально работает «Яндекс погода» 😁

А уже во вторник (9 июня), на воркшопе «API и Postman на реальных примерах» будем разбирать реальную документацию Яндекс погоды и обрабатывать запросы

Если хотите лучше разобраться с API и Postman, приходите!

✌️Подробности тут ✌️

📌 Архитектура на собеседовании

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


👉 Что обычно спрашивают:

1️⃣ Монолит, SOA или микросервисы — в чём разница и когда что выбирать
2️⃣ Синхронные и асинхронные интеграции — HTTP, брокер, когда что уместно
3️⃣ Высокоуровневая схема — как описать систему за 5–10 минут: пользователь → фронт → API → сервисы → БД
4️⃣ Нефункциональные требования — нагрузка, отказоустойчивость, масштабирование
5️⃣ Компромиссы — почему «идеальной» архитектуры не бывает


👉 Как отвечать, чтобы не провалиться:

▫️ Начни с контекста: «Для какого масштаба и этапа продукта мы проектируем?»
▫️ Назови 2–3 ключевых компонента и связи между ними — не рисуй 20 блоков
▫️ Обоснуй выбор: «Берём брокер, потому что уведомления не должны блокировать оформление заказа»
▫️ Упомяни риски: единая точка отказа, сложность отладки, согласованность данных


На Junior+ часто достаточно уверенно объяснить монолит vs микросервисы и нарисовать простую схему с API Gateway и двумя сервисами.

На Middle ждут, что ты свяжешь архитектуру с бизнес-целями и НФТ.


💡 Главное: на собеседовании оценивают не зубрёжку определений, а умение думать про систему целиком.

Системный аналитик не обязан быть разработчиком

Но если в проекте есть API, интеграции и обмен данными — делать вид, что "это техническая часть, пусть разработчики сами разберутся", уже не получится

Потому что именно аналитик часто должен понять:

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

И для этого нужно уметь работать с Postman нормально:
прочитал документацию → собрал запрос → настроил auth → отправил → разобрал ответ → понял ошибку → сформулировал вывод

9 и 16 июня проводим практический воркшоп:

«API и Postman на реальных примерах»

Уже завтра первый день!

Разберём, как системному аналитику работать с API руками:

— настройка Postman;
— первый запрос;
— перенос данных из API-документации;
— Params, Headers, Body, Auth;
— Basic Auth, API Key, OAuth 2.0;
— REST и GraphQL;
— ответы, ошибки и типовые проблемы;
— домашнее задание и разбор.

Стоимость:

1990 ₽ — участие онлайн
2990 ₽ — онлайн + записи

Это воркшоп для аналитиков, которые хотят увереннее чувствовать себя в API-задачах

Завтра начинаем, осталось меньше 50-ти мест:
🤩Забрать место на воркшопе

Postman за пару тысяч

Если у вас на работе уже появляются API-задачи, разработчик кидает "проверь запрос", в вакансиях пишут Postman, а на собеседовании могут спросить, как вы проверяете API — откладывать дальше не получится...

Postman обычно вспоминают не заранее, а когда уже надо. И вот тогда начинается: какой метод выбрать, куда вставить параметры, что делать с headers, почему вернулся 400 и это я сломал запрос или API реально работает криво?

Уже сегодня (в 19:00 мск) проводим воркшоп по Postman

Разберём руками то, что аналитику реально нужно: отправить запрос, посмотреть ответ, понять статус-код, найти ошибку и нормально объяснить её команде

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

Участие — 1 990 ₽ онлайн и 2 990 ₽ с записями

За эти деньги можно заказать один ужин (и то, на одного). А можно наконец разобраться с Postman и облегчить себе жизнь в карьере аналитика

Осталось около 20-ти мест:
🤩Забрать место на воркшопе

Старт сегодня в 19:00 мск!

Подробнее о воркшопе

Если остались вопросы — пишите в Telegram: @care_sa

📝 Задача | Архитектура

Условие:

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

Вводные:
▫️ ~50 000 записей в день, пики утром и вечером
▫️ Есть веб и мобильное приложение
▫️ Расписание врачей хранится в CRM клиники — интеграция по REST API
▫️ Уведомления должны уходить даже если CRM временно недоступна после создания записи

Задание:
1. Назови основные компоненты системы (3–6 штук).
2. Опиши поток: пользователь записался → что происходит дальше.
3. Объясни, где уместна синхронная интеграция, а где асинхронная — и почему.


⏱️ Попробуй решить сам.
Разбор опубликуем 10.06 в первой половине дня по мск

Пиши ответ в комментариях 👇

✅ Решение | Архитектура · Запись к врачу

Краткий ответ:

Компоненты: Web/Mobile → API Gateway → Сервис записи → CRM (REST) + Брокер → Сервис уведомлений → Email/Push-провайдер. БД записи — у сервиса записи.


📖 Разбор:

1️⃣ Компоненты

▫️ API Gateway — единая точка входа для веба и мобилки
▫️ Сервис записи — бизнес-логика: проверка слота, создание записи, своя БД
▫️ CRM клиники — внешняя система с расписанием (REST)
▫️ Брокер сообщений — очередь событий «запись создана»
▫️ Сервис уведомлений — читает из брокера, шлёт email и push


2️⃣ Поток

Пользователь выбирает слот → Gateway → Сервис записи синхронно проверяет слот в CRM → создаёт запись у себя в БД → кладёт событие в брокер → сразу отвечает пользователю «Запись создана».

Сервис уведомлений асинхронно забирает событие и отправляет письмо и push. Если CRM упала после успешного создания записи — пользователь уже получил ответ, уведомление уйдёт позже из очереди.


3️⃣ Синхрон vs асинхрон

Синхронно (REST к CRM) — проверка и бронирование слота. Пользователь должен сразу узнать: слот свободен или занят.

Асинхронно (брокер) — уведомления. Не блокируем ответ пользователю, переживаем временные сбои email/push за счёт повторной обработки из очереди.


❌ Типичные ошибки:

▫️ Всё через синхронные вызовы — при падении push-сервиса пользователь не получит ответ о записи
▫️ CRM как единственная БД записей — потеря контроля над своими данными и зависимость от чужого SLA
▫️ Брокер для проверки слота — лишняя сложность, пользователь ждёт мгновенный результат


💡 На собеседовании важно: назвать почему граница между sync и async проходит именно здесь.

📂 Кейс: «Почему вы не взяли Kafka?» — вопрос с собеседования, который стал реальным проектом

🏢 Контекст:

Маркетплейс доставки еды, ~200 заказов в минуту в пик. Команда из 8 разработчиков, монолит на Python, один PostgreSQL. Собеседование на Middle SA — тестовое: предложить целевую архитектуру на 12 месяцев.


😬 Проблема:

Кандидат на схеме нарисовал 6 микросервисов, Kafka и Redis "как в статьях". На защите тестового техлид спросил: "Зачем Kafka при 200 заказах и команде из 8 человек? Как будете дебажить?"

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


🔍 Что сделал аналитик (уже на проекте, тот же вопрос от бизнеса):

1. Собрал НФТ: пик 200 зак/мин, рост до 500 за год, RTO 30 мин
2. Выделил узкое место: не заказы, а расчёт времени доставки из трёх внешних сервисов (карты, курьеры, кухня)
3. Предложил поэтапно:
— Сейчас: вынести расчёт ETA в отдельный сервис + кэш Redis (синхронный REST для заказа остаётся)
— Через 6 мес.: события «заказ создан» в RabbitMQ для уведомлений и аналитики
— Kafka — только при выходе на 500+ и появлении event streaming для отчётов
4. Зафиксировал в ADR: почему не Kafka на старте (операционная сложность, нет consumer-групп на объёме)


✅ Результат:

Архитектурный комитет принял roadmap без "микросервисов ради микросервисов". Через 4 месяца ETA-сервис снизил таймауты на 40%. RabbitMQ добавили точечно — под уведомления.


💡 Выводы:

▫️ На собеседовании и на проекте побеждает не самая модная схема, а обоснованная под контекст
▫️ Вопрос "почему не X?" важнее, чем "мы взяли X"
▫️ Аналитик связывает НФТ, команду и этап продукта — не только рисует блоки


Кстати, у нас идет обновление курса "Архитектура для аналитика", скоро вернется в новом формате. Мы делим большой курс на два уровня:
База — чтобы перестать плавать в архитектуре
Hard — для сложных архитектурных решений
Подробности на сайте. Оставь заявку, чтобы первым получить уведомление о запуске!

Кажется, мы дошли до той стадии развития сообщества, когда аналитика можно узнать не только по ноутбуку 😄

У нас есть классный мерч:

👕 футболки с аналитическими надписями

🎲 настольная игра для системных аналитиков

Теперь главный вопрос...

А вы вообще хотели бы такой мерч себе?

Давайте честно оценим уровень желания по шкале системного аналитика:

🔥 «Хочу сильнее, чем заказчик хочет поменять требования после согласования»

👌 «Взял бы, если не придётся писать ТЗ на получение мерча»

💯«Готов обменять на него пару диаграмм и один use case»

👏«Уже мысленно пришёл на созвон в этой футболке»

👍 «Где записаться в очередь и почему это ещё не user story?»

Пишите свой вариант в комментариях

🧠 Опрос: Архитектура на собеседовании

Классикой нашего канала стала рубрика вопросов/ответов. 4 вопроса в формате технического интервью. Выбирай ответ и пиши комментарии, сразу после каждого вопроса публикуем разбор.