📚 Задача с собеседования на Senior СА: 10 ошибок и 1 ловушка в схеме архитектуры 📚

Публикую ответ к задаче на ревью C4/Container-схемы архитектуры платформы постаматов. Подобную задачу могут предложить на собеседовании системного аналитика.


Вот что было спрятано на схеме👇


1️⃣ Непоследовательное использование цветов

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


2️⃣ Нестандартная форма API Gateway не объяснена

Шестиугольник допустим как авторское обозначение, но его значение необходимо закрепить в легенде или обговорить в команде. В C4 нет правила «API Gateway — шестиугольник».


3️⃣ В подписях связей осталось e.g.

e.g. JSON/HTTP — это пример из шаблона, а не описание интеграции. На схеме должны быть указаны фактические данные и протокол: JSON/HTTPS, Protobuf/gRPC, JSON/Kafka protocol и другие.


4️⃣ Неверно обозначена граница системы

Контур подписан как Container, хотя внутри уже находятся контейнеры. Это граница Software System, в которую также должны входить приложение постамата и административная панель.


5️⃣ Два API Gateway без обоснованной необходимости

Для семи сервисов Public API Gateway и Admin API Gateway создают лишнюю сложность. В рамках задачи достаточно одного Gateway с разными маршрутами и политиками доступа.


6️⃣ Маркетплейс напрямую подключён к внутренней Kafka

Внешняя система не должна знать внутреннее устройство backend. В этой задаче запросы маркетплейса принимаем через REST API и публичный API Gateway, а изменения статусов передаём через Webhooks. Это более универсальное и применимое решение, чем брокер.


7️⃣ Постамат обращается напрямую к сервису

Если аутентификация и другие общие проверки настроены на API Gateway, прямой маршрут позволяет их обойти.

В предложенном решении устройства подключаются через защищённую точку входа с аутентификацией и проверкой прав конкретного постамата. Для MQTT может использоваться специализированный IoT- или MQTT-шлюз, либо общий шлюз с поддержкой MQTT.

В данной схеме это не то, чтобы ошибка, но точно место, на которое стоит обратить внимание.


8️⃣ Уведомления отправляются синхронно

Недоступность SMS- или email-провайдера не должна останавливать основной процесс. События передаём через Kafka или RabbitMQ, а сервис уведомлений обрабатывает их независимо.


9️⃣ Firebase добавлен без бизнес-сценария

У системы нет собственного клиентского приложения для получателя. Push-уведомления отправлять некуда, поэтому Firebase в текущей архитектуре не нужен.


🔟 Планировщик запускает задачи синхронно

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


✅ Общая БД — ловушка, а не ошибка

У неопытных аналитиков часто встречается правило:
«Если микросервисы, то каждому обязательно нужна отдельная физическая БД».
Но это не так.

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

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



Все материалы по задаче:

📚🔥 Полный разбор с пояснениями
✔️ Исходная схема
✔️ Схема с отмеченными ошибками
✔️ Исправленная схема архитектуры

Доступны по ссылке + прикреплены к посту.


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


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