Как строилась архитектура проекта и почему были выбраны определенные решения
Что проверяют
Умеете ли вы объяснить архитектуру через причины решений, альтернативы и их цену. Для бэкенда на Java интервьюер особенно смотрит, понимаете ли вы, когда монолит лучше микросервисов и как сервисы общаются между собой. Следом спрашивают про согласованность данных между сервисами.
Как отвечать
Идите от требований к решениям на своём проекте:
- ограничения: нагрузка, объём данных, требования к согласованности, размер команды, сроки. Архитектура выводится из них, а не из моды;
- форма системы: модульный монолит на Spring Boot или микросервисы. Микросервисы оправданы при независимых командах и разном профиле нагрузки, иначе модульный монолит с проверяемыми границами модулей (ArchUnit, Spring Modulith) дешевле;
- внутренняя структура: слоистая или гексагональная архитектура, где домен не зависит от фреймворка;
- взаимодействие: синхронно через REST или gRPC, асинхронно через Kafka или RabbitMQ. Для согласованности между сервисами: паттерн outbox, саги, идемпотентные потребители;
- данные: PostgreSQL как выбор по умолчанию, NoSQL под конкретную модель доступа, Redis для кэша с понятной стратегией инвалидации;
- эксплуатация: таймауты, ретраи и circuit breaker через Resilience4j, метрики через Micrometer и Prometheus, трассировка, контейнеры и Kubernetes.
У каждого пункта называйте причину и цену и приводите свои цифры: RPS, задержки, частоту релизов. Если архитектуру проектировали до вас, опишите, как её понимаете, что в ней мешало и что бы вы поменяли.
Где спотыкаются
Начинают с «мы выбрали микросервисы» без объяснения зачем. Интервьюер сразу спросит, почему не монолит, и ответа не окажется.
Не могут объяснить, как обеспечена согласованность, когда операция затрагивает два сервиса. Вызов второго сервиса внутри локальной транзакции её не даёт, а двухфазный коммит в микросервисах почти не применяют.
Приводят круглые проценты ускорения без базовой линии и способа замера. Одна честная цифра с методикой убедительнее трёх красивых.