Опишите архитектуру типичного микросервисного веб-приложения с фронтендом и бэкендом
Что проверяют
Умеете ли вы разложить обычное веб-приложение по слоям, не сползая в пересказ статьи, и понимаете ли, чем платят за деление на сервисы. Для позиции на Go отдельно слушают устройство самого сервиса внутри: таймауты, отмена, завершение работы.
Как отвечать
Ведите по пути запроса. Статика и приложение в браузере отдаются с раздачи или сети доставки контента. Запросы за данными идут на балансировщик и шлюз, который завершает TLS, проверяет токен, режет лишнее лимитами и маршрутизирует дальше. За шлюзом сервисы, у каждого своя база: чужие данные берутся вызовом или приходят событием, общая на всех база превращает набор сервисов обратно в монолит.
Внутренний обмен: HTTP и JSON наружу, gRPC между своими, если нужен строгий контракт, шина событий там, где ответ не нужен немедленно. Назовите сквозные вещи: идентификатор запроса и трассировка, метрики и логи в едином формате, версионирование контрактов, миграции схемы отдельным шагом выката.
Про Go говорите предметно: context.Context первым параметром и прокинутый до запроса в базу, таймаут у каждого клиента, ограничение числа одновременных обращений к соседу, errgroup для параллельных вызовов, корректное завершение по сигналу, настроенный пул соединений к базе.
Где спотыкаются
Рисуют схему на десять сервисов, не отвечая, зачем их столько. Следом обычно спрашивают про команду из пяти человек: для неё разумнее модульный монолит, который потом режут по готовым швам.
Второе: забывают про поведение при отказе соседа. Без таймаутов, ограничения повторов и идемпотентности одна медленная зависимость складывает всю цепочку, а повторы добивают её окончательно.
Третье: http.Client без таймаута и горутина на каждый вызов. Пока сосед отвечает медленно, сервис копит горутины и соединения, память растёт, и он падает раньше того, кто сломался первым.