Где может быть проблема, если запрос возвращает 200, но в базе данных нет новой записи

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

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

Как отвечать

Идите по цепочке от запроса к базе и на каждом шаге проверяйте факт:

• тело ответа: часть API отдаёт 200 и пишет ошибку внутрь, например {"success": false}. Смотрите в DevTools или Postman тело, а не только код. Заодно проверьте метод: GET ничего не создаёт, а на создание ресурса обычно ждут 201;
• асинхронность: сервис мог положить задачу в очередь (Kafka, RabbitMQ) и ответить сразу. Запись появится после консьюмера или не появится, если он упал. Смотрите очередь, dead letter queue и логи обработчика;
• транзакция: ответ ушёл до коммита, а коммит откатился из-за ошибки или ограничения базы;
• не та база: другой стенд, схема или тенант, чтение с отстающей реплики, запись только в кэш;
• не та запись: строка есть, но вы ищете по другому полю, она мягко удалена флагом, или сработал upsert и обновилась существующая строка;
• заглушка: запрос ушёл в мок или шлюз, который отвечает 200 без похода в сервис.

Главный инструмент здесь идентификатор запроса. Если сервис возвращает X-Request-Id или trace id, по нему в Kibana или Grafana находятся все логи, и видно, дошёл ли запрос до записи.

В баг-репорт: curl запроса, полный ответ, время, стенд, request id и SQL, которым вы проверяли базу.

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

Смотрят только на статус и не открывают тело ответа, где сервер уже написал, что пошло не так.

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

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