Как происходит процесс проработки задач от бизнеса и кто отвечает за добавление таблиц и интеграцию сервисов

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

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

Как отвечать

Опишите цепочку с ролями:

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

Про таблицы скажите прямо: схемой владеет команда сервиса, которому принадлежат данные. Новая таблица появляется как миграция Liquibase или Flyway в репозитории сервиса, проходит ревью вместе с кодом и накатывается конвейером, а не руками на сервере. Spring Boot запускает миграции при старте приложения, если библиотека есть в зависимостях. DBA подключается к ревью тяжёлых изменений: индексы на больших таблицах, блокирующие ALTER, перенос данных.

Про интеграцию: контракт согласуется до реализации. Для REST это спецификация OpenAPI, для событий схема в Schema Registry (Avro или Protobuf) или AsyncAPI. Чтобы контракт не ломался молча, пишут consumer-driven тесты на Spring Cloud Contract или Pact. Изменения делают обратно совместимыми: сначала добавить поле, потом перевести потребителей, потом удалить старое.

Приведите пример из своего проекта: какую таблицу добавляли, с кем согласовывали контракт, что пошло не так.

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

Отвечают «таблицы добавляет DBA по заявке». Если у вас так, скажите, но покажите, что знаете про миграции в коде и почему без них окружения расходятся.

Не различают, кто владеет данными. Два сервиса, которые пишут в одну таблицу, это общая база и скрытая связность, интервьюер это заметит.

Забывают про обратную совместимость: переименовали колонку или поле в JSON одним релизом и сломали потребителей, которые обновятся через неделю.