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

🧮 Как оценить эффективность IT-команды: оценка задач аналитика и ценность его работы 🧮

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

Вместе с Сергеем Кругловым, Chief Product Owner в компаниях ITECH и Vetsy, рассуждаем о том, какую ценность аналитик привносит в команду разработки и как оценивать его работу. Разбираем, какие KPI и метрики помогают отследить эффективность аналитика, и предлагаем практические советы по планированию и оценке задач.


🔗 Сайт эпизода


Погрузитесь в тему оценки задач — и станьте сильнее как аналитик и как тимлид!


Эпизод доступен в:
⏯ Apple Podcast
⏯ Яндекс.Музыка
⏯ Telegram
⏯ Castbox
⏯ Звук
⏯ Spotify
⏯ RuTube
⏯ YouTube
⏯ VK Video


Сообщество GetAnalyst — место, где аналитики растут быстрее. Присоединяйтесь! 💫

🟠 Интеграции по REST, GraphQL и WebSocket: от Postman до требований в Confluence 🔵

Приглашаем вас на открытый урок, где мы поможем вам выстроить системный подход к работе с интеграциями — от анализа внешнего API до структурированной постановки задач в Confluence.


💥 Интеграции по REST, GraphQL и WebSocket:
от Postman до требований в Confluence

Доступ к записи
🗓 с 28 до 30 июня (сб - пн)

🔗 ЗАРЕГИСТРИРОВАТЬСЯ


В результате занятия:
🟢 Освоите порядок работы над интеграциями и научитесь быстро вникать в API
🟢 Попрактикуетесь в Postman: запросы, ответы, сценарии тестирования
🟢 Познакомитесь с нюансами GraphQL и WebSocket
🟢 Поймёте, какие диаграммы нужны и как их использовать при проектировании
🟢 Получите шаблон постановки задачи в Confluence и разберёте типичные ошибки

Это обучение - вводный урок к практической программе Интеграции систем.


Регистрируйтесь сейчас, чтобы получить новый опыт! 🙌🎓

✨ Подборка примеров схем архитектуры ✨

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


👉 Архитектура системы
Это структурированное описание компонентов системы (приложения, базы данных, API, брокеры, внешние сервисы и др.), связей между ними и принципов их взаимодействия.

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


👉 Зачем аналитикам её понимать?

✅ Видеть, как проходят данные между компонентами и кто инициирует процессы — пользователь, система, внешний сервис.

✅ Писать корректные интеграционные Use Case.

✅ Учитывать зависимости между компонентами при доработках — например, если изменится логика одного сервиса, кто еще пострадает?


👉 На картинке к посту
пример архитектурной схемы проекта #TravelGA в формате простых фигур и в нотации С4.

Благодаря этой схеме легко проследить, что происходит при переходе к оплате экскурсии через внешнюю систему ВТБ:

1. Пользователь нжимает кнопку оплаты в любом фронт-приложении.
2. Фронт обращается к Backend через REST API.
3. Backend вызывает внешнюю систему ВТБ по REST API.
4. ВТБ возвращает ответ о создании платежа на Backend.
5. Backend сохраняет ответ по созданной платёжной операции в БД.
6. Backend возвращает результат на фронт.
7. Фронт обрабатывает ответ и на основе данных из него переключается на платежную форму.



👇 Ниже — ещё несколько примеров архитектур и пояснений к ним, чтобы вы развивали насмотренность, в том числе на сложных проектах:

Монолит
🔗 RideFlow [С4] - заказ такси
🔗 TelMed [С4] - телемедицина
🔗 EventTaskGA - синхронизация задач по организации мероприятий с внешней системой

Микросервисная архитектура (МСА)
🔗 FarmFreshGA - доставка фермерских продуктов
🔗 RideFlow - заказ такси

МСА с брокерами:
🔗 BookingGA [С4] - сервис аренды недвижимости
🔗 GreenChargeGA [С4] - зарядки для электроавто


Изучайте и применяйте в работе 🙌

#ИнтеграцииGA #АрхитектураGA #vtbAPI

💳 9 типовых Use Case для Интеграции с платежной системой 💳

Разбираемся, какие Use Case охватывает интеграция с платёжной системой (PSP), и какие методы понадобятся для её реализации на примере API ВТБ 👇


1️⃣ Создание транзакции
Отправляем сумму и детали заказа.
Получаем ссылку на платёжную форму, id и другие параметры платежа.
Перенаправляем пользователя по ссылке.
Пользователь вводит данные карты на форме оплаты.
Оплата завершается.
---
Метод: Регистрация заказа


2️⃣ Подтверждение оплаты (Webhook)
Платёжная система сама сообщает статус оплаты.
Надо делать метод на стороне нашей системы, чтобы его вызвала платежная система.
---
Метод: Уведомления обратного вызова


3️⃣ Проверка статуса платежа (Polling)
Если webhook не сработал (т.е. у нас в БД статус платежа всё ещё "ожидание оплаты"), то прежде чем показать пользователю итоговый статус платежа, надо перепроверить его на стороне платежной системы.
---
Метод: Статус заказа


4️⃣ Отмена платежа
Пока деньги не списаны, пользователь в любой момент может прервать оплату
---
Метод: Отмена заказа


5️⃣ Возврат средств
Полный или частичный, если надо удержать комиссию.
Нужен, если пользователь отказывается от оказания услуги
---
Метод: Возврат средств


6️⃣ Сохранение платёжных данных
Для One-Click и подписок.
Чтобы пользователю не надо было вводить карту при последующих покупках.
Важно! На стороне нашей системы хранится только id платежного средства, а все данные карты (номер, CVV, дата окончания) будут храниться безопасно, на стороне платежной системы.
---
Метод: обычно внутри первой оплаты


7️⃣ Повторное списание
Автоплатежи без участия пользователя
---
Метод: Рекуррентный платеж


8️⃣ Формирование отчётов
Всё для бухгалтерии и бизнеса.
Обычно на основании внутренних данных, которые сохранялись в нашей системе по итогам платежей.


9️⃣ Работа с чеками
Иногда делают такие доп. сценарии. Зависит от потребностей бизнеса


Сохраняйте, если работаете над задачами с оплатой или только собираетесь вникать в платёжные сценарии 👌

#ИнтеграцииGA #TravelGA #vtbAPI

🔎 Интеграция с ВТБ: анализ API-документации, часть 2 🔎

Продолжаем исследование API-документации платежной системы ВТБ 👇


✅ Ограничения и особенности
В API-документации ВТБ ограничения, лимиты на кол-во запросов и другие особенности не приводятся.
Хотя они точно есть, судя по наличию обрабатываемого кода ошибки HTTP-429.
🔗Пример в другом API



✅ Общие требования к обработке ошибок
Полный перечень:
🔗Стандартные коды ошибок
Не всегда есть.

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

Чтобы понять, как система реагирует, например, на создание заказа с суммой 0₽, нужно обязательно проводить исследовательское тестирование через Postman.



✅ Список методов для нашей задачи
На этом этапе важно понимать логику будущего алгоритма работы системы.

Обычно я сначала продумываю интерационные Use Cases, не зная деталей внешнего API. А потом подбираю нужные методы.

ВТБ упростил мою задачу и написал интеграционный Use Case за меня.
И ссылки на все методы добавили в него, и схему сделали (на картинке к посту) 😀
Спасибо команде платежной системы ВТБ!

🔗 Интеграционный Use Case - в нем ссылки на API-документацию методов, которые нам необходимы (register.do, paymentorder.do и другие)

🔗 Все API-методы



📞 Обратные вызовы / Callback / Webhook
Почти в любой платёжной интеграции нужно:
✔ получить подтверждение статуса оплаты от платежной системы,
✔ обработать уведомление на стороне вашего Backend.

Интегрируетесь с платежкой?
Ищите подобный раздел в документации.

🔗 Уведомления обратного вызова


------

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


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


#ИнтеграцииGA #TravelGA #vtbAPI

🔎 Интеграция с ВТБ: анализ API-документации, часть 1 🔎

Интеграция с платёжной системой — одна из тех задач, которые аналитик должен уметь решать:

1️⃣ Здесь почти всё, что важно: работа с внешним API, WebHook, обработка критических ошибок (потому что 💸)

2️⃣ Такие задачи часто встречаются — от запуска MVP до оптимизации ПО и снижения комиссий для бизнеса.

Это как «боевое крещение»: если разобрался с платёжками, то с любыми интеграциями уже не страшно.


👉 В этих постах я покажу свой подход к анализу API-документации внешних систем, и соберу все важные данные по API в одном месте.

Отмечу особенности для интеграции с платёжками.


✅ Документация
Главный раздел


✅ Вид API
✔ Нигде явно не указан.
✔ HTTPs-запросы.
✔ Все POST.
Все POST = HTTP API.
Но похоже, что ВТБ стремятся быть REST-ом, судя по ключу "rest" в URL


✅ Авторизация и аутентификация
Нестандартная, через тело запроса Body.
Есть два варианта:
✔ Используя логин и пароль API-пользователя, передаются в параметрах userName и password
✔ С помощью специального токена, передается в параметре token
🔗 Документация тут

🔐 Есть усиленные меры по безопасности:
Может потребоваться реализовать асимметричную подпись запроса с помощью специального сертификата.
🔗 Документация тут



✅ Тестовые доступы
Есть два URL для API:

TEST:

https://vtb.rbsuat.com/payment/rest/

PROD:

https://platezh.vtb24.ru/payment/rest/

Можно бесплатно зарегистрировать свой личный кабинет на тестовом окружении.

Инструкция по созданию тестового ЛК:
Тестовая площадка → Попробовать → Войти → Внизу формы входа кнопка "Создать учетную запись"
🔗Страница регистрации


✅ Рекомендации по использованию API
Так как на рынке много решений по платёжкам (ТБанк, Сбер, PayPal и др.) и среди них высокая конкуренция за бизнес-клиентов, то рекомендаци по интеграции есть почти всегда.

У ВТБ около 10 способов интеграции и по каждому описан рекомендуемый сценарий:
🔗 Документация

Наш вариант:
🔗 Прямые платежи

Этот раздел в разы упрощает работу аналитика.


Далее 👉 в ч.2

#ИнтеграцииGA #TravelGA #vtbAPI

🚀 Открыта предзапись на Интеграции: старт 2 июля 🎓

Интеграции - один из самых востребованных навыков для системных аналитиков. Каждая третья вакансия на hh.ru требует знаний и опыта в интеграциях, особенно в ведущих ИТ-компаниях рынка.

В программе "Интеграции систем" мы на практике разбираем все детали работы с задачами: от анализа API-документации до создания структуры требований и постановок задач на разработчиков.


🗓 Старт обучения: 2 июля 2025
🔗 Подробнее о программе и прием заявок


Вас ждут:
✅ 10 живых онлайн-встреч
✅ Решение реальных задач
✅ Один проект в течение всей программы
✅ Обратная связь и индивидуальный подход
✅ Структурированные знания и опыт


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

⚡ Пример технического Use Case с брокером в микросервисной архитектуре⚡


👉 Задача:
Нужно корректно завершить сессию, рассчитать оплату, списать деньги и уведомить пользователя.


👉 Проект:
#GreenChargeGA - зарядка электрических автомобилей


👉 Предусловия:
▫️ Пользователь завершает зарядку электромобиля на станции.
▫️ В его аккаунте уже привязана банковская карта.



👉 Система должна:
➕ зафиксировать окончание зарядки
➕ рассчитать потреблённую энергию и стоимость
➕ провести списание средств через эквайринг
➕ тправить уведомление
➕ начислить бонусы
➕ передать данные в аналитику


Все шаги проходят через брокер сообщений Kafka, который играет роль хореографа — он направляет выполнение событий:
✅ где-то в строго заданной последовательности,
✅ где-то — независимо, но не параллельно в прямом смысле, а асинхронно, по мере готовности подписчиков на брокер.



📎 В прикреплённом документе пример технического Use Case —
не просто “что делает пользователь”, а как работает система под капотом, какие внутренние и внешние интеграции есть, и как они организованы через событийно-ориентированную архитектуру (EDA).

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


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

🔵 C4 / Container — итоговая схема микросервисной архитектуры с брокером для проекта #GreenChargeGA 🔵

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

В этой публикации — обновлённая схема и разбор архитектурных ошибок и проблем, которые удалось устранить:


❌ Нет связи от Firebase к фронтам с push-уведомлениями
✅ Добавлены.
На первом этапе пытались минимизировать линии и пересечения, но без них схему нельзя считать полной.


❌ Синхронизация только через один API Gateway
✅ Для синхронизации данных между микросервисами внедрён брокер событий.

Ранее все внутренние синхронизации шли через один и тот же Gateway, обрабатывающий внешние и внутренние запросы — это создавало риски перегрузки и уязвимости в одной точке.

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

Альтернативой мог быть отдельный Gateway для внутренних вызовов.


❌ Всё синхронно внутри? Не надёжно
✅ Если бы мы пошли по пути отдельного Gateway, взаимодействие между микросервисами оставалось бы синхронным.

Вместо этого внедрили Kafka — для асинхронной коммуникации, снижения связанности и повышения отказоустойчивости.


🥲 Надо ещё брокеров
✅ RabbitMQ, использовавшийся для уведомлений, заменён на Kafka — надёжное решение для потоков событий и хореографии микросервисов.
Это повысило отказоустойчивость и снизило связанность.


❌ Не показаны WebHooks от платежных систем
✅ Добавлены двусторонние стрелки вызовов.
По схеме теперь видно, что платёжные системы вызывают нас обратно при смене статуса платежа.



📚 Связанные материалы по проекту GreenChargeGA:
▫️ C4 / Context
▫️ C4 / Container - версия с проблемами
▫️ Часть архитектуры с демо хореографии



Сохраняйте, изучайте, обсуждайте 💙

И помните — архитектура не бывает финальной. Но она должна быть продуманной.

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

📚🎧 Интеграции для СА и БА: актуальная подборка материалов 🎧📚

Длинные выходные — редкая возможность совместить отдых и саморазвитие.

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


Маленький шаг к лучшей версии себя — уже сегодня 😉


Послушать и посмотреть:

🎧 Подкаст "Проблемы в работе с задачами на интеграции"

📹 Postman: навык тестирования REST API за вечер

📹 Опасные интеграции - про альтернативные сценарии и обработку типовых ошибок

🎧 Подкаст "Идемпотентность и коммутативность API: что это и как применяют на практике" - про проблемы дубликатов запросов

🎧 Подкаст "Что такое вебхуки (Webhooks) и зачем они нужны" - оптимизация работы интеграций

📹 Доставить и не потерять: синхронизация данных в распределенных системах - основы очередей сообщений

🎧 Подкаст "Kafka: что нужно знать Системному аналитику" - глубже в понимание очередей и брокеров

🎧 Подкаст "RabbitMQ и его отличия от Kafka: что важно знать системным аналитикам"


Практические руководства по Postman:

📚 Практическое руководство по Postman - тестирование API DaData (с нуля до результатов)

📚 Практическое руководство по Postman - тестирование API ChatGPT

📚 Практическое руководство по Postman - тестирование API Unisender


Шаблоны постановок задач:

💎 Полный интеграционный Use Case - рассылка email через Unisender (с брокерами и микросервисами)

💎 Полный интеграционный Use Case - автоматическое создание задач во внутренней системе ToDoist для сотрудников компании после оплаты заказов

💎 Интеграционный REST API-метод - структурирование адресов через DaData



Ещё больше про интеграции:

🎓 Практический курс Интеграции Систем - работа онлайн с Екатериной Ананьевой и экспертами программы

🎓 Материалы для самообучения по Интеграциям (пакеты вебинаров)



Всё по интеграциям от GetAnalyst вы всегда можете найти в канале по хэштегу #ИнтеграцииGA 🙌


Прекрасных выходных!

🛠️ Особенности Use Cases для Интеграций — разбор с примерами 🛠️

Use Case — это:
▫️ детализированные функциональные требования;
▫️ описание, как пользователь взаимодействует с системой для достижения цели;
▫️ сценарий, который показывает шаги пользователя и системы в процессе выполнения задачи;
▫️ алгоритм работы системы.


👉 Стандартный шаблон Use Case:
▪ Предусловие
▪ Роли пользователей
▪ Приложения и системы
▪ Входные данные
▪ Основной сценарий
▪ Обработка ошибок и альтернативные сценарии
▪ Ожидаемый результат

👉 Интеграционный Use Case дополняется:
▪ техническими деталями по вызовам API методов, которые аналитику важно прописать в постановке задачи,
▪ а также маппингом данных.


Важно понимать, что Интеграции — это не просто "еще одна задача".

Это серьезная работа по анализу взаимосвязей
+ БД
+ Функций
+ UI/UX
+ API нашей и внешних систем,
которая требует нашего опыта, внимания и профессионализма 🙌

Мини-книгу про отличия обычных Use Case от интеграционных прикрепила к посту 🤝

#ИнтеграцииGA

✅ Интеграции: чек-лист по работе с задачами ✅

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

Хочу поделиться с вами пошаговым планом, описывающим этот процесс.

Пусть он станет вашим помощником при работе с задачами на интеграции и в подготовке к собеседованиям.


👉 Краткий чек-лист по работе с задачами на интеграции:

☑️ Получить вводные от заказчика
☑️ Выделить компоненты системы: внешние, внутренние
☑️ Найти API-документацию для каждого из внешних сервисов, а если необходимо, то и для внутренних
☑️ Нарисовать схему архитектуры — первое приближение
☑️ Описать процессы, которые нужно поддержать в системе
☑️ Найти по API-документации соответствующие процессам методы, добавить их в описание
☑️ Уточнить схему архитектуры (и далее постоянно актуализировать по ходу детального проектирования и постановок задач)
☑️ Получить доступы к API
☑️ Протестировать API своими силами или с помощью разработчиков
☑️ Сопоставить наборы данных, доработать/спроектировать БД нашей системы при необходимости, описать маппинг данных
☑️ Создать задачи в Jira и выстроить порядок разработки
☑️ Сделать детализацию постановок задач в Confluence на основе исследований, проведенных ранее


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

#ИнтеграцииGA

🧩 Новый проект на интеграцию: бронирование экскурсий в #TravelGA с оплатой через ВТБ 🧩

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


🟢 Задача:
В текущих мобильных и веб-приложениях #TravelGA реализован только просмотр экскурсий.
Цель — добавить функциональность бронирования и онлайн-оплаты эксскурсий через платёжную систему ВТБ.


🟢 Сценарии к проектированию:
1. Пользователь выбирает одну или несколько экскурсий и оплачивает бронирование.

2. Пользователь отменяет часть оплаченных экскурсий (или все) и оформляет возврат, если это допустимо по правилам экскурсии.


👉 Что предстоит сделать Системному Аналитику:
1. Выделить ключевые Use Case
2. Провести первичный анализ API-документации ВТБ: наличие нужных методов, рекомендуемый порядок интеграции
3. Определить влияние интеграции на архитектуру системы
4. Протестировать платёжное API ВТБ в Postman, чтобы понять, как он реально работает
5. Описать интеграционные Use Cases: логику работу системы с техническими деталями
6. Сформировать требования для интеграционных REST API-методов
7. Дополнить требования UML-диаграммами
8. Описать маппинги данных и доработки БД

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


🟢 Результаты
✔️ Полные постановки задач на интеграцию с банком
✔️ Коллекция Postman-запросов для API ВТБ
✔️ Отработанный кейс интеграции от анализа до реализации


Хотите участвовать? Подписывайтесь на GetAnalyst и следите за обновлениями 😉

Добро пожаловать в наш интеграционный проект!

#ИнтеграцииGA #vtbAPI

📚 Мини-книга по Интеграциям для Системных аналитиков: самое важное 📚

Интеграция — это процесс объединения различных систем и приложений в единое целое, чтобы они могли работать вместе, обмениваться данными и выполнять задачи, как одна система.


👉 Пример 1
Платформа по доставке еды хочет отправлять клиенту SMS о процессе доставки.

Надо ли этой платформе:
1. Покупать оборудование для отправки SMS?
2. Заключать договоры и делать интеграции со всеми операторами сотовой связи?

Конечно, нет.
Мы подключаем готовый SMS-сервис (например, Unisender) через API — и задача по доставке SMS решена 🙌


👉 Пример 2
Тот же сервис доставки хочет принимать оплату банковскими картами.

Надо ли ему:
1. Реализовывать проверку карты?
2. Поддерживать 3-D Secure?
3. Хранить токены и проходить банковскую сертификацию PCI DSS?

Нет. Мы просто подключаем готовое решение по API, например, от ТБанка.


Главная идея интеграций:

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

👉 Виды интеграций:

1) по окружениям:
▫️ Внешние - когда мы хотим подключить к нашей системе чужую, от других разработчиков.
▫️ Внутренние
- на проекте сервисная или микросервисная архитектура, сервисы обмениваются данными по API или через брокеры.
- мобильное приложение работает с данными благодаря интеграции с сервером по API.

2) по направлению:
▫️ Во внешние системы - когда мы используем API чужих систем.
▫️ К нашей системе - когда мы сами разрабатываем свой API, чтобы к нам подключались (например, по примеру выше, мы банк, и даем другим свой API для подключения)


👉 Способы обмена данными:
▫️ Синхронный - отправили данные и получили ответ сразу.
▫️ Асинхронный - отправили данные и продолжили работу без ожидания ответа. Обработка в фоне.


👉 Основные способы интеграции:
▫️ API
▫️ Библиотеки и SDK
▫️ Брокеры
▫️ Файлы
▫️ Общая БД



📚 Подробнее об интеграциях рассказала в мини-книге с картинками и примерами.

Файл прикреплен к посту.

Загружаем, изучаем и используем 👍

#ИнтеграцииGA

Я не планировала выкладывать это сейчас… Но не могу удержаться ❤️‍🔥🥰😻

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

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

Такие слова нельзя просто оставить в архиве 😊

Спасибо!
Что не боитесь идти вглубь.
Что выбираете системность.
Что растёте на наших глазах.

Вы — вдохновляете 💚🦭

#АрхитектураGA #студентыGetAnalyst

💃 Хореография в микросервисах: разбор примера для #GreenChargeGA 🕺

Хореография — это подход, при котором каждый сервис самостоятельно реагирует на события, происходящие в системе.

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

Координация действий происходит через брокер сообщений: Kafka, RabbitMQ и др.

👉 Важно для понимания!
Брокер это место хранения сообщений, как временная БД, и он ничем не управляет, а только временно хранит события к обработке.


Каждый микросервис:
✅ подписан на определённые события в брокере,
✅ обрабатывает их, когда они появляются,
✅ не знает, какие другие сервисы участвуют в процессе.


👉 Пример 1:
Завершение зарядки электромобиля на станции GreenChargeGA

🟢 После завершения сессии зарядки Сервис Телеметрии публикует событие charging.finished в брокер.


Что происходит дальше:

1. Сервис Платежей получает событие charging.finished, списывает средства с карты пользователя и публикует событие payment.success.

2. Сервис Лояльности слушает событие об успешной оплате payment.success и начисляет бонусы. После чего генерирует событие о добавлении бонусов loyalty.bonusAdded.

3. Сервис Уведомлений слушает события payment.success и loyalty.bonusAdded и отправляет пользователю уведомление с итогами.

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

Все шаги выполняются в фоне, это пример гибкой и масштабируемой архитектуры.



👉 Пример 2
Пользователь завершил настройку профиля

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

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

🟢 Событие profile.setupCompleted — публикуется в брокер от Сервиса Управления Пользователями, когда пользователь завершил заполнение профиля.

Подписанные микросервисы:
🔸 Сервис Уведомлений — отправляет приветственное сообщение с подсказками по началу использования.
🔸 Сервис Лояльности — активирует стартовые бонусы в рамках приветственной кампании.
🔸 Сервис Аналитики — сохраняет событие завершения настройки для последующего анализа поведения новых пользователей.

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



Преимущества хореографии:

💫 Масштабируемость:
Можно легко подключить новые сервисы, которые будут реагировать на события.
Например, маркетинговый сервис, который будет запускать цепочку писем — просто подписав его на profile.setupCompleted.

💫 Устойчивость:
Ошибки одного сервиса не мешают другим.

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


Часть схемы архитектуры проекта с хореографией:
🔗 [открыть схему архитектуры C4]

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

💃 Хореография и Оркестрация в микросервисной архитектуре 🎻

В микросервисной архитектуре (МСА) есть два основных подхода для управления работой сервисов:
💃 хореография,
🎻 оркестрация.

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


Например, завершение зарядки электромобиля — это не просто «всё, машина заряжена».
Это триггер для цепочки действий:
🔸 списание оплаты с карты,
🔸 начисление бонусов по программе лояльности,
🔸 отправка уведомления.


С точки зрения архитектуры, этот процесс может быть реализован по-разному:

📌 Хореография
Каждый сервис сам знает, что делать при наступлении определенного события в системе.

Взаимодействие между сервисами происходит через брокер сообщений (обычно Kafka), без централизованного управляющего компонента.

Сервисы подписываются на события в брокере, такие как charging.finished («завершение зарядки»), payment.success («оплата проведена успешно»), и реагируют на них независимо друг от друга.

Например, сервис бонусов может слушать событие об успешной оплате и начислить бонусы, а сервис уведомлений — сформировать и отправить сообщение пользователю.


📌 Оркестрация
Здесь управление процессом сосредоточено в отдельном компоненте — оркестраторе.

Пример оркестратора “из коробки”: Camunda.

Оркестратор вызывает нужные микросервисы по порядку (например: сначала — платёж, затем — бонусы, потом — уведомление) и отслеживает результат выполнения каждого этапа.

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



Оба подхода имеют свои преимущества и применяются в зависимости от целей:

💃 Хореография подходит для гибких, масштабируемых систем с высокой степенью независимости компонентов;

🎻 Оркестрация — для сценариев, требующих строгой последовательности, централизованного контроля и отслеживания хода выполнения.


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

🧩 Как встроить Kafka в архитектуру, и главное зачем: разбор на примере проекта #GreenChargeGA 🧩

Ранее мы спроектировали схему архитектуры проекта для станций зарядки электро-авто.

Но если в архитектуре не использовать брокер сообщений, а делать прямые синхронные вызовы между микросервисами (через REST/gRPC), могут возникнуть проблемы:

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

➖ Если хотя бы один сервис при обработке сложного запроса не отвечает, перегружен или упал, исходный запрос зависает или падает с ошибкой

➖ Сложность в аналитике и аудите

Чтобы решить их, в архитектуру встраивают брокеры сообщений.



Давайте разберём как это работает на примере:
👉 Сценарий обработки события окончания зарядки



👉 Без брокера

1. Сервис Телеметрии отправляет запрос на API Gateway об окончании зарядки

2. API Gateway проксирует его на Сервис Платежей

3. Сервис Платежей регистрирует кол-во израсходованной энергии, определяет цену и списывает средства с банковской карты, привязанной к ЛК пользователя

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

5. Сервис Платежей вызывает Сервис Уведомлений для отправки уведомления

6. Возврат ответа на Сервис Телеметрии об успешной обработке события завершения зарядки

❌ Проблема:
Если Сервис Программы Лояльности или Сервис Платежей недоступны, то....? Начинаем "городить костыли" в алгоритме с ретраями (повторами) и не только... 🥲



👉 С брокером Kafka

1. Сервис Телеметрии отправляет событие (сообщение) charging.finished в Kafka об окончании зарядки, в топик charging-events. ✅ На этом он выполнил свою миссию по зарядке и более ничего не ждёт.

2. Сервис Платежей подписан на топик charging-events и событие charging.finished в Kafka. Он забирает оттуда это событие, когда готов и не нагружен (хоть сразу, хоть через 3 часа)

3. Сервис Платежей обрабатывает это событие:

3.1. Регистрирует кол-во израсходованной энергии, определяет итоговую цену и списывает средства с карты

3.2. Отправляет событие о списании средств charging.paid в Kafka, топик charging-events
✅ На этом Сервис Платежей выполнил свою миссию и более ничего не ждёт.

4. На событие charging.paid в топике charging-events подписаны Сервисы Программы Лояльности и Уведомлений.
Когда они будут готовы, то тогда и заберут в обработку событие, и каждый обработает его по отдельности.


✅ Преимущества:
Даже если сервисы Платежей, Лояльности или Уведомлений будут недоступны или будут реагировать ошибкой, необработанное событие об окончании зарядки / завершении платежа будет храниться в брокере и ожидать обработки.

Обычно обработка происходит очень быстро, что процесс выглядит как-будто синхронно, но на самом деле это не так. За счёт брокера мы организовали фоновую обработку событий (=задач), когда один сервис не ждёт завершения работы другого.

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



👉 Итого получаем:
Внедренный механизм асинхронной обработки событий с использованием Kafka сделал систему более устойчивой к сбоям и гибкой для масштабирования.



Если ещё не изучали Kafka, то здесь можно найти самые важные материалы:
🔗 ссылка


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