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

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

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


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


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

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

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

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


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

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


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


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



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



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

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

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