Выбранный слот ещё не занят в системе
Условные посетители А и Б одновременно открыли страницу и увидели свободное время. Оба нажали на него. Это локальный выбор в двух интерфейсах, а не два подтверждённых бронирования. Между выбором и результатом есть запрос к серверу. Пока ответ не получен, нужно показывать ожидание. Надпись запись подтверждена появляется только после достоверного подтверждения сохранения. Иначе пользователь может принять предварительное действие за завершённую запись и планировать свои дела на ложном основании.
Проверка и сохранение должны защищать одно правило
Правило модели простое: у одного слота не может быть двух активных записей. Если сервер отдельно проверяет свободное время, а затем без защиты сохраняет запись, два параллельных запроса способны пройти проверку до сохранения любого из них. Поэтому целостность обеспечивают на уровне операции с данными, например подходящим ограничением уникальности и обработкой конфликта. Для модели фиксированных слотов это понятная основа. Если длительность приёмов произвольная и интервалы пересекаются, требуется уже другая проверка, которую нельзя заменить простым сравнением времени начала.
Конфликт является ожидаемым исходом
Если А получил подтверждение первым, Б должен увидеть, что выбранное время больше недоступно. Это не повод показывать неясную техническую ошибку или обещать запись обоим. Интерфейс обновляет доступные варианты и помогает продолжить выбор, сохраняя допустимую часть введённой информации. Сообщение должно объяснять ситуацию без раскрытия сведений о другом посетителе. Достаточно факта недоступности слота. При отмене записи правило освобождения времени тоже должно быть определено явно, чтобы старые записи не путались с активными.
Неизвестный ответ требует проверки результата
Сеть может прерваться после сохранения записи, но до получения подтверждения браузером. В таком случае отсутствие ответа не доказывает, что операция не выполнилась. Система должна уметь выяснить её результат или безопасно обработать повтор того же запроса. Идентификатор операции помогает связать повтор с первоначальной попыткой, а не создавать ещё одну запись. Отключённая кнопка полезна для интерфейса, но не заменяет серверную защиту: запросы могут повторяться по разным причинам. Важно проверять и параллельность, и повторную отправку.
Попробуйте на практике
Разберите конкурентную запись на один вымышленный слот с помощью карточек, без запуска сервиса.
- Нарисуйте слот 14:00 и две карточки посетителей А и Б. Отметьте, что оба увидели его свободным и выбрали локально.
- Проведите запрос А через сохранение и подтверждение. Для Б покажите конфликт с правилом одной активной записи.
- Запишите сообщения каждого интерфейса: подтверждение для А и предложение выбрать другое время для Б. Не добавляйте сведения о другом человеке.
- Отдельно представьте потерю ответа для А после сохранения. Опишите проверку результата по той же операции вместо создания новой записи.
Как проверить результат. У слота осталась одна активная запись. Выбор отделён от подтверждения, конфликт обработан понятно, а потеря ответа не вызвала слепого повторного бронирования.
Частые вопросы
Достаточно ли заблокировать кнопку после нажатия?
Нет. Это уменьшает случайные повторные нажатия, но не защищает от параллельного запроса другого пользователя и повторов на уровне сети или клиента.
Подходит ли правило уникального времени для любых записей?
Нет. В этом примере слоты фиксированы и не пересекаются. Для разных длительностей, ресурсов и вместимости модель ограничений нужно определить отдельно.
Самостоятельный разбор темы. Содержание конкретной обучающей программы здесь не представлено.