Какая у тебя любимая архитектура?

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

Есть ли у вас инженерная позиция и понимаете ли вы, что архитектуру выбирают под задачу, а не под вкус. Следом почти всегда спрашивают: «А когда бы вы от неё отказались?»

Как отвечать

Сильный ответ называет подход, условия, в которых он хорош, и его цену. Для Go-разработчика стоит говорить на двух уровнях.

Уровень системы:

• модульный монолит: один деплой, но пакеты с явными границами. Хороший старт для небольшой команды: нет сетевых вызовов между модулями и распределённых транзакций;
• микросервисы: оправданы, когда команды должны выкатываться независимо или части системы нагружаются по-разному. Цена: сетевые отказы, согласованность через саги или outbox, трейсинг, инфраструктура на каждый сервис.

Уровень кода внутри сервиса:

• слоистая или гексагональная структура: транспорт (HTTP, gRPC), бизнес-логика, хранилище. Зависимости направлены внутрь, логика не знает про net/http и SQL;
• интерфейсы на стороне потребителя: в Go интерфейс объявляют там, где он используется, и делают маленьким. Принцип «принимай интерфейсы, возвращай структуры» упрощает подмену в тестах;
• пакеты по предметной области: order и payment вместо models и services, а закрытое прячут в internal/.

Вывод может звучать так: «Мне ближе модульный монолит с чистыми границами, а в отдельные сервисы выношу то, что требует независимого масштабирования или релиза». Подкрепите это своим случаем: что делили, что получилось, о чём жалеете.

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

Отвечают «микросервисы» как единственно верное. Без условий это звучит как следование моде, особенно если в вашем опыте система была небольшой и её вела одна команда.

Переносят в Go привычки из Java: интерфейс на каждую структуру заранее, пакеты interfaces и impl, тяжёлые DI-контейнеры. В Go-коде это выглядит чужеродно, и интервьюер это заметит.

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