Заказ создан, ответ потерян: как избежать дублей и возвратов

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

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

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

Это самостоятельный бизнес-сценарий, который проектируют вместе с основным потоком заказа.

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

Запрос не дошёл - заказа у перевозчика нет.

Запрос дошёл, но обработка завершилась ошибкой - заказа нет.

Заказ создан, но подтверждение потеряно - у магазина нет внешнего идентификатора. Один и тот же тайм-аут не позволяет отличить эти варианты. Поэтому решение нельзя строить только на коде ответа.

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

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

Для операций с созданием заказа, списанием или возвратом это важнее, чем удобство автоматического повтора.

Идемпотентный ключ работает только тогда, когда получатель закрепил его смысл в контракте API и хранит результат операции.

Собственный идентификатор отправителя без поддержки на стороне получателя не предотвращает дубль.

Поиск по номеру заказа и журнал отправок снижают риск, но не дают гарантии уникальности.

Событие «доставлен», «частично доставлен» или «проблема» само по себе может быть недостаточным.

Для корректного финансового и товарного результата системе нужны номер заказа, строки, количество и версия события.

Если событие пришло без состава заказа, нельзя автоматически заключать, что товары потеряны или заказ пуст.

Такой сигнал должен попасть в техническую очередь на повторную обработку или сверку.

Для входящих событий полезно хранить идентификатор события, время возникновения, версию или последовательность.

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

Чем необратимее действие, тем больше подтверждений ему нужно.

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

Автоматический возврат по одному тайм-ауту создаёт риск повторной компенсации.

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

Надёжная интеграция доставки определяется не тем, как она работает при идеальном ответе, а тем, что происходит после тайм-аута.

Система должна уметь отличать «не создан» от «создан, но не подтверждён», безопасно повторять операции, восстанавливать идентификаторы и блокировать необратимые действия при неопределённости.

Для аудита KT.Team берёт один поток создания заказа, таблицу статусов и примеры тайм-аутов.

Результатом становятся схема восстановления, перечень необратимых действий и набор сценариев отказа для приёмки.