Кто принимает решения по архитектуре микросервисов
Что проверяют
Представляете ли вы, как принимаются архитектурные решения в компании, где сервисов и команд больше одного, и где в этом процессе ваше место. Следом обычно спрашивают, было ли у вас несогласие с принятым решением и что вы с ним делали.
Как отвечать
Хороший ответ делит решения по масштабу, потому что у разных уровней разные владельцы:
- внутри сервиса: команда, которая им владеет, во главе с техлидом. FastAPI или Django, синхронный или асинхронный код, структура модулей, ORM или чистый SQL;
- границы сервисов и контракты: техлиды затронутых команд вместе с архитектором. Что выделять в отдельный сервис, кто владеет данными, REST, gRPC или события через Kafka и RabbitMQ;
- общие для компании правила: архитектурный комитет или платформенная команда. Единая трассировка через OpenTelemetry, стандарт логов, разрешённые базы и брокеры, требования безопасности;
- бизнес и продукт: технологии не выбирают, но задают ограничения, от которых архитектура зависит: нагрузку, сроки, требования к доступности, бюджет.
Дальше про процесс. Решения, которые трудно отменить, оформляют письменно: RFC для обсуждения и ADR (Architecture Decision Record) с контекстом, рассмотренными вариантами и причиной выбора. Через год по нему можно понять, почему сделано именно так. Можно вспомнить закон Конвея: границы сервисов обычно повторяют границы команд, поэтому архитектурное решение часто оказывается ещё и организационным.
Закончите своим примером: какое решение вы предлагали или оспаривали, какие были аргументы (замер, прототип, стоимость поддержки) и чем всё закончилось.
Где спотыкаются
Отвечают «решает архитектор» или «решает вся команда». Оба ответа слишком общие: интервьюер ждёт разделения по уровням и понимания, кто отвечает за последствия.
Путают архитектуру с выбором библиотек. Архитектура это прежде всего границы, данные и способы взаимодействия, а не выбор между requests и httpx.
Не могут назвать ни одного своего вклада. Даже джуниор может сказать, что участвовал в обсуждении RFC или нашёл узкое место на прототипе.