В чем может быть причина проблемы с сохранением клиента в базе данных

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

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

Как отвечать

Идите по пути запроса сверху вниз:

• клиент: во вкладке Network в DevTools проверьте, ушёл ли запрос, что в теле, какой код ответа. Если запроса нет, проблема на фронтенде: валидация формы, ошибка в консоли, заблокированная кнопка;
• ответ API: 400 или 422 обычно значат, что не прошла серверная валидация, 409 конфликт (например, дубль email), 500 падение на бэкенде. Отдельный подозрительный случай: 200 или 201 без записи в базе, значит исключение где-то проглочено;
• логи: по X-Request-Id или trace id найдите запрос в логах бэкенда (Kibana, Grafana Loki, что есть в проекте) и текст ошибки;
• база: проверьте запись прямым SELECT. Типичные причины отказа: NOT NULL на поле, которое форма не передаёт, UNIQUE на почте или телефоне, внешний ключ на несуществующую запись справочника, строка длиннее varchar(50), эмодзи в имени при кодировке utf8 вместо utf8mb4 в MySQL, миграция не накатилась на этот стенд;
• транзакции: запись откатилась из-за ошибки в соседнем шаге, двойной клик породил гонку или дубль.

Если запись в базе есть, а в интерфейсе её нет, ищите в чтении: фильтр мягкого удаления, кэш, реплика с задержкой, другой тенант или окружение.

В баг-репорт кладите шаги, тестовые данные, запрос и ответ, фрагмент лога и результат запроса к базе.

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

Останавливаются на «ошибка на бэкенде» без локализации. Разработчику придётся повторить всю вашу работу.

Верят успешному коду ответа и не проверяют саму запись в базе.

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