Есть ли опыт разработки архитектуры сервисов

Что проверяют

Умеете ли вы принимать архитектурные решения и объяснять их цену, а не перечислять технологии. Следом почти всегда идёт «почему так, а не иначе» и «что бы вы сейчас сделали по-другому».

Как отвечать

Возьмите один реальный проект и расскажите его по слоям, цифры и детали только свои:

• контекст: что делала система, нагрузка, размер команды, ограничения по срокам и инфраструктуре;
• границы сервисов: по какому признаку разделили (домен, команда, профиль нагрузки). Оставили монолит, это тоже решение, его стоит защитить;
• взаимодействие: синхронно через gRPC или REST, асинхронно через Kafka или NATS, где что и почему;
• надёжность: таймауты и отмена через context.Context, ретраи с экспоненциальной задержкой и идемпотентность, graceful shutdown через signal.NotifyContext и http.Server.Shutdown;
• согласованность данных: как не потерять событие между записью в базу и отправкой в очередь (transactional outbox), где понадобилась сага;
• наблюдаемость: метрики Prometheus, трассировка OpenTelemetry, структурные логи на log/slog;
• итог: что сработало, что сломалось, что бы вы переделали.

Если архитектуру с нуля вы не проектировали, так и скажите и опишите реальный уровень: писали сервис в готовой схеме, участвовали в дизайн-ревью, готовили design doc или ADR на свою часть, выносили модуль из монолита. Затем покажите ход мысли на их задаче: какие вопросы зададите и какие варианты рассмотрите. Честный средний уровень с хорошими рассуждениями ценится выше, чем приписанный себе чужой проект.

Где спотыкаются

Перечисляют стек вместо решений: «Go, REST, Postgres, Prometheus, CI/CD». Интервьюеру нужны альтернативы и причины выбора.

Присваивают себе архитектуру всей системы, хотя писали один сервис. На третьем уточняющем вопросе это становится видно.

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