Перенос бронирования без потери слота: проверки и защита от сбоев

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

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

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

Атомарность означает применение связанных изменений целиком или отказ от них целиком. Документация PostgreSQL объясняет этот принцип на транзакциях базы данных. Применительно к календарю команда может использовать его, чтобы согласованно изменить занятость старого и нового интервала. Это проектное решение, которое зависит от устройства системы.

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

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

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

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

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

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

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

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