На каких архитектурах писали и какие плюсы и минусы вы видите

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

Опыт за пределами одного шаблона проекта и умение назвать цену решения. В Go вопрос почти всегда про два уровня сразу: как устроена система из сервисов и как устроен код внутри одного сервиса.

Как отвечать

Разложите ответ на два слоя, иначе разговор уйдёт в общие слова.

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

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

Уровень сервиса на Go:

• слои транспорта, сценариев и хранилища, где зависимости направлены внутрь, а интерфейсы объявлены на стороне потребителя;
• раскладка по каталогам вроде cmd и internal, чтобы внутренние пакеты нельзя было импортировать извне;
• зависимости через конструкторы, context.Context первым аргументом, чтобы отмена доходила до запроса в базу.

Про Go полезно сказать отдельно: язык не любит лишние слои, и пять интерфейсов вокруг одного запроса выглядят чужеродно.

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

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

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

Переносят слои из другого языка вместе с фабриками и интерфейсом на каждый тип. В Go интерфейс вводят там, где есть вторая реализация или нужна подмена в тесте, иначе он добавляет файл и не добавляет ничего больше.