⭐️ Kafka - что надо знать для работы Системному аналитику ⭐️

Apache Kafka — это распределённая платформа потоковой обработки данных.

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


Основные компоненты:

✔️ Продюсеры (Producers)

1) Генерируют сообщения/события к обработке и отправляют в топики (темы).

2) Определяют, в какую партицию топика записывать данные: автоматически или по заданным правилам.

3) Могут быть чем угодно: микросервисы, устройства IoT и другие приложения.

4) Поддерживают режимы отправки:
+ Синхронный — ждёт подтверждения от Kafka перед отправкой следующего сообщения.
+ Асинхронный — отправляет сообщения без ожидания ответа.

5) Могут гарантировать доставку с разными уровнями подтверждения (acks):
+ acks=0 — без ожидания подтверждения (возможна потеря данных, высокая скорость).
+ acks=1 — подтверждение только от лидера партиции (среднее).
+ acks=all — подтверждение от всех реплик (максимальная надёжность).


✔️ Потребители (Consumers)

1) Подписываются на один или несколько топиков и получают сообщения/события.

2) Могут работать как отдельные клиенты или объединяться в группы (Consumer Groups) для параллельной обработки сообщений.

3) В группе консьюмеров каждый участник обрабатывает свою часть партиций.

4) Kafka гарантирует, что каждое сообщение будет обработано хотя бы одним потребителем в группе.

5) Модели доставки сообщений:
+ at-least-once — как минимум 1 раз, возможны дубликаты.
+ exactly-once — ровно один раз.


✔️ Топики (Topics) — логическая тема, куда продюсеры отправляют сообщения, а потребители их читают


✔️ Партиции (Partitions) — подмножество данных внутри топика, которое позволяет распределять нагрузку и масштабировать обработку сообщений. Каждый топик состоит из одной или нескольких партиций


✔️ Брокер (Broker) — сервер Kafka, который отвечает за хранение, управление и передачу данных внутри кластера


✔️ Кластер — это группа брокеров, работающих вместе для масштабирования и распределённой обработки данных


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

⭐️ Устройство Kafka: топики, партиции, брокеры, кластеры ⭐️


✔️ Топики (Topics)

1) Логическая категория или тема, куда Продюсеры отправляют сообщения, а Потребители их читают.

2) Представляют собой поток сообщений, где каждое имеет: ключ, значение, метаданные.

3) Не удаляют сообщения сразу после обработки — данные хранятся в топике в течение заданного времени.

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


✔️ Партиции (Partitions)

1) Каждый топик состоит из одной или нескольких партиций (разделов).

2) Сообщения внутри партиции хранятся в строгом порядке (FIFO — "первым пришёл, первым обработался").

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

4) Каждое сообщение в партиции получает уникальный порядковый номер (offset), который используется Потребителями для чтения данных.

5) Продюсеры могут отправлять сообщения в партиции автоматически или по определённому ключу (например, все заказы одного клиента попадут в одну партицию).

6) Один потребитель из Группы Консьюмеров читает данные только из своей партиции, что позволяет распределять нагрузку.

7) Повышение надежности обеспечивается через репликацию: выделяют Leader Replica (основная копия данных партиции) и Follower Replica (копирует данные лидера в синхронном или асинхронном режиме).


✔️ Брокеры (Brokers)

1) Хранят топики и их партиции.

2) Обрабатывают запросы Продюсеров на запись и Консьюмеров на чтение данных.

3) Управляют репликацией партиций для отказоустойчивости.

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



✔️ Кластер (Cluster)

1) Это группа брокеров, работающих вместе для масштабирования и распределённой обработки данных.

2) Использует ZooKeeper или KRaft для координации (назначает лидеров партиций, отслеживает состояние брокеров).

3) Позволяет добавлять новые брокеры без остановки системы.

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


#Архитектура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

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