Дубли онлайн-записи: как защитить бронь при повторном запросе

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

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

Не смешивайте два вида проблем. Повторная отправка одного намерения создаёт лишнюю копию заказа. Конкуренция разных клиентов за последний слот — другая задача, требующая корректного резервирования вместимости. Решение одной проблемы не доказывает, что система защищена от другой.

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

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

Нужно различать идентификатор операции, номер брони и карточку клиента. Первый связывает технические повторы, второй обозначает созданный заказ, третья объединяет историю человека. Очистка дублей контактов в CRM не является защитой от повторного бронирования.

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

В вашем процессе срок хранения должен покрывать ожидаемые повторы и восстановление после сбоев. Согласуйте, что произойдёт, если отложенный запрос придёт позже этого срока. Нельзя бесконечно отправлять старое создание заказа и рассчитывать, что система всегда узнает первоначальную попытку.

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

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

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

Рекомендуемая прикладная схема: сохранить номер исходной брони в связанных объектах, учитывать тип выполняемого действия и хранить его состояние. Тогда восстановление после сбоя продолжает незавершённый этап, а не создаёт всю цепочку заново. Конкретная реализация зависит от возможностей систем и не сводится к одному полю в форме.

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

Если результат оплаты неизвестен, не предлагайте немедленно создать ещё один платёж. Сначала проверьте исходную операцию у платёжного провайдера и согласуйте состояние заказа. Аналогично, отсутствие сделки в CRM не доказывает отсутствие брони: источники могут обновляться в разное время.

Попросите показать повтор одного запроса после потерянного ответа и объяснить, как найти созданную запись. Отдельно проверьте параллельные вызовы и изменение параметров. Эти проверки дают больше информации, чем общее обещание «дубли исключены».

Уточните границы ответственности MySlot, сайта и внешних сервисов. Наличие API или вебхуков не означает автоматической защиты всей цепочки. Результат проверки и ограничения лучше включить в условия приёмки интеграции.