Использовалась ли одна база данных на сервис или разные
Что проверяют
Насколько вы понимаете архитектуру, в которой работали, и умеете ли объяснить компромиссы, а не повторить «у каждого микросервиса своя база». Следом обычно спрашивают, как вы обеспечивали согласованность данных между сервисами и кто владел миграциями.
Как отвечать
Отвечайте про свой проект, но разделяйте логический и физический уровни:
- своя база у сервиса (database per service): сервис единолично владеет своими таблицами, другие получают данные только через его API или события. Плюсы: независимые релизы и миграции, хранилище под задачу. Минусы: нет JOIN между доменами и нет общей транзакции;
- общий кластер, отдельные схемы или пользователи: частый компромисс. Физически один PostgreSQL, логически у каждого сервиса своя схема и свои права, чужие таблицы он не видит;
- общая база на всё: быстрый старт, но любая миграция затрагивает все сервисы, и система превращается в распределённый монолит.
Затем покажите, как это выглядело в Go-коде: у каждого сервиса свой пул pgxpool или *sql.DB, свои миграции через goose или golang-migrate в репозитории сервиса, запросы через sqlc или вручную. Для согласованности между сервисами расскажите, что использовали: паттерн outbox (событие пишется в той же транзакции, что и данные, а отдельный процесс публикует его в Kafka), саги с компенсирующими действиями, CDC через Debezium.
Цифры и детали берите из своего опыта: сколько сервисов, какие базы, что болело. Если работали только с общей базой, так и скажите, объясните, почему команда так решила, и опишите, что изменили бы при росте нагрузки или числа команд.
Где спотыкаются
Отвечают теорией без привязки к проекту. Вопрос про ваш опыт, и интервьюер это заметит сразу.
Приукрашивают: заявляют «у каждого сервиса своя база» и не могут объяснить, как строили отчёт, которому нужны данные трёх сервисов.
Называют круглые цифры вроде «время отклика упало на 30%», не зная, как это мерили. Следующий вопрос будет про метрику и инструмент, и выдуманная цифра развалится.