💻 Kafka в деле: подробный разбор примера использования в МСА 💻

Рассказываю про внутреннюю интеграцию через Kafka и, в завершении проекта с микросервисами #BookingGA, показываю на нём наглядный пример.


📌Процесс:
Оплата бронирования жилья


📌Сложность:
Сразу после оплаты надо в фоне (асинхронно) выполнить несколько внутренних задач. Обеспечить гарантию их выполнения.


📌Алгоритм:
1. Пользователь произвел платеж за аренду в любом Frontend-приложении.

2. Сразу после завершения оплаты, с Frontend идёт запрос на Backend (API Gateway) для проверки статуса платежа, т.к. оплата проводилась на стороне внешней платежной системы и надо подтвердить её успех на бэке.

3. API Gateway перенаправляет запрос на Сервис Платежей, который:
+ выполняет проверку статуса в системе RaifPay
+ обновляет статус платежа в БД
+ кладёт событие (сообщ.) об оплате 👉в Kafka(4), чтобы на него среагировали связанные сервисы - это нужно для дальнейшей асинхронной работы системы

-> После этого Сервис Платежей возвращает успешный ответ на API Gateway

-> API Gateway возвращает успешный ответ с актуальным статусом платежа на Front

-> Front показывает пользователю "Платеж успешен"


4. Сообщение попадает в Kafka, в определенные топик и партицию, которые предназначены для событий "Платеж успешен".

Сервисы Уведомлений, Бронирований и Аналитики (Консьюмеры) подписаны на этот топик Kafka, с событиями "Платеж успешен".


5. Далее, каждый сервис по отдельности, в любом порядке и когда ему удобно, забирает и обрабатывает событие (сообщ.) "Платеж успешен":

5.1. Уведомления: отправляет email/sms о платеже
5.2. Бронирования: подтверждает бронь и обновляет статус в БД
5.3. Аналитики: получает данные для отчетов и сохраняет в свою БД


Kafka гарантирует, что даже если какой-то сервис недоступен сразу, в реальном времени, то событие об оплате он всё равно получит и обработает позже, когда включится 🛡


Полезное:
🔗 C4/Container - исходная схема
🔗 Брокеры VS Очереди
🔗 Kafka: что нужно знать СА
🔗 Устройство Kafka: определения+визуал

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