💃 Хореография в микросервисах: разбор примера для #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

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

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

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

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

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

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

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

🧩 Новый проект на интеграцию: бронирование экскурсий в #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

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

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

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


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


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

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

📹 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 🙌


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

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

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

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


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


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


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

🔎 Интеграция с ВТБ: анализ 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

🔎 Интеграция с ВТБ: анализ 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

💳 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

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

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

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


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


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


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


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