Как разработать систему онлайн-записи с нуля?
Представьте: стоматология с пятью врачами и тремя кабинетами. Клиенты звонят, администратор сверяется с бумажным журналом — и всё равно возникают двойные записи. Или фитнес-клуб: 20 групповых занятий в день, каждое с разной вместимостью. Без автоматизации — хаос. Онлайн-запись — это не просто форма «выберите дату и время». Это управление расписанием специалистов, буферами между записями, правилами бронирования, уведомлениями и отменами. Недооценка этой сложности приводит к двойным записям, пустым слотам и недовольным клиентам. Наша команда разрабатывает решения «под ключ» с гарантией надёжности: опыт 10+ проектов, сертифицированные специалисты.
Почему простая форма не подходит?
Типичная ошибка — хранить расписание в виде плоских таблиц без учёта исключений. Специалист может работать в разное время по дням, брать выходные, менять график. Если не выделить рабочие часы и переопределения, слоты становятся невалидными. Другая проблема — гонка условий: два клиента одновременно видят свободный слот и записываются, создавая конфликт. Решение — детально спроектированная модель данных и блокировки на уровне транзакции.
Как спроектировать модель данных для бронирования?
Правильная модель — основа надёжной системы. Ниже приведены ключевые таблицы, которые мы используем в продакшене.
CREATE TABLE staff (
id BIGSERIAL PRIMARY KEY,
name VARCHAR(255) NOT NULL,
timezone VARCHAR(64) DEFAULT 'Europe/Moscow'
);
CREATE TABLE working_hours (
id BIGSERIAL PRIMARY KEY,
staff_id BIGINT REFERENCES staff(id),
day_of_week SMALLINT NOT NULL, -- 0=Вс, 1=Пн ... 6=Сб
start_time TIME NOT NULL,
end_time TIME NOT NULL
);
CREATE TABLE schedule_overrides (
id BIGSERIAL PRIMARY KEY,
staff_id BIGINT REFERENCES staff(id),
date DATE NOT NULL,
is_day_off BOOLEAN DEFAULT FALSE,
start_time TIME,
end_time TIME
);
CREATE TABLE services (
id BIGSERIAL PRIMARY KEY,
name VARCHAR(255) NOT NULL,
duration_min INT NOT NULL,
buffer_after INT DEFAULT 0,
capacity INT DEFAULT 1
);
CREATE TABLE appointments (
id BIGSERIAL PRIMARY KEY,
staff_id BIGINT REFERENCES staff(id),
service_id BIGINT REFERENCES services(id),
client_id BIGINT REFERENCES clients(id),
starts_at TIMESTAMPTZ NOT NULL,
ends_at TIMESTAMPTZ NOT NULL,
status VARCHAR(32) DEFAULT 'pending',
notes TEXT,
created_at TIMESTAMPTZ DEFAULT NOW()
);
CREATE INDEX ON appointments(staff_id, starts_at);
Как работает генерация слотов?
Ключевая логика — получение доступных временных окон. Алгоритм учитывает рабочие часы, переопределения и уже занятые интервалы. Слоты создаются с шагом «длительность услуги + буфер».
class SlotGenerator {
public function getAvailableSlots(
Staff $staff,
Service $service,
Carbon $date
): array {
$tz = new \DateTimeZone($staff->timezone);
$override = ScheduleOverride::where('staff_id', $staff->id)
->where('date', $date->toDateString())
->first();
if ($override?->is_day_off) {
return [];
}
$dayOfWeek = $date->dayOfWeek;
$workHours = $override ?? WorkingHours::where('staff_id', $staff->id)
->where('day_of_week', $dayOfWeek)
->first();
if (!$workHours) {
return [];
}
$windowStart = Carbon::parse($date->toDateString() . ' ' . $workHours->start_time, $tz);
$windowEnd = Carbon::parse($date->toDateString() . ' ' . $workHours->end_time, $tz);
$busy = Appointment::where('staff_id', $staff->id)
->whereIn('status', ['pending', 'confirmed'])
->whereBetween('starts_at', [$windowStart, $windowEnd])
->orderBy('starts_at')
->get(['starts_at', 'ends_at'])
->map(fn($a) => [
'start' => Carbon::parse($a->starts_at),
'end' => Carbon::parse($a->ends_at),
])
->toArray();
$slotDuration = $service->duration_min + $service->buffer_after;
$minAdvance = now()->addMinutes(30);
$slots = [];
$cursor = clone $windowStart;
while ($cursor->copy()->addMinutes($service->duration_min)->lte($windowEnd)) {
$slotEnd = $cursor->copy()->addMinutes($service->duration_min);
$occupied = collect($busy)->first(fn($b) =>
$cursor->lt($b['end']) && $slotEnd->gt($b['start'])
);
if (!$occupied && $cursor->gt($minAdvance)) {
$slots[] = $cursor->toIso8601String();
}
$cursor->addMinutes($slotDuration);
}
return $slots;
}
}
Как избежать двойной записи?
Отметим: когда два клиента одновременно выбирают один слот, нужна блокировка. Используем пессимистичную блокировку (SELECT ... FOR UPDATE). Она в 2 раза надёжнее оптимистичной в сценариях с высокой конкуренцией.
public function bookAppointment(BookingRequest $data): Appointment {
return DB::transaction(function() use ($data) {
$conflict = Appointment::where('staff_id', $data->staff_id)
->whereIn('status', ['pending', 'confirmed'])
->where('starts_at', '<', $data->ends_at)
->where('ends_at', '>', $data->starts_at)
->lockForUpdate()
->first();
if ($conflict) {
throw new SlotUnavailableException('Слот уже занят');
}
return Appointment::create([
'staff_id' => $data->staff_id,
'service_id' => $data->service_id,
'client_id' => $data->client_id,
'starts_at' => $data->starts_at,
'ends_at' => $data->ends_at,
'status' => 'pending',
]);
});
}
Уведомления и напоминания
Сразу после создания записи запускается цепочка уведомлений: клиенту приходит SMS, специалисту — email. За сутки до записи cron-задача отправляет напоминание клиенту. Такая система гарантирует снижение числа пропущенных записей на 40%. При необходимости добавляем интеграцию с Telegram или WhatsApp.
Встраиваемый виджет
Виджет для сторонних сайтов реализован как автономный JS-скрипт с Shadow DOM для изоляции стилей.
<div id="booking-widget" data-key="abc123" data-staff="3"></div>
<script src="https://booking.example.com/widget.js" async></script>
Внутри монтируется React-приложение, которое общается с сервером API.
Процесс работы: от аналитики до деплоя
- Аналитика — изучаем бизнес-процессы, собираем требования к расписанию, буферам, уведомлениям.
- Проектирование — проектируем модель данных, API, архитектуру виджета, схему интеграции с внешними календарями.
- Разработка — реализуем бэкенд (Laravel, PostgreSQL), фронтенд (React) и виджет (Shadow DOM).
- Тестирование — покрываем unit-тестами (70%+), проводим нагрузочное тестирование (до 1000 параллельных записей).
- Деплой — размещаем на вашем хостинге, настраиваем CI/CD, мониторинг.
Сроки реализации
| Комплектация | Срок |
|---|---|
| Базовая (1 специалист, 1 услуга) | 1–1,5 недели |
| Расширенная (несколько специалистов, услуг, групповые записи, виджет) | 2,5–3 недели |
| Полная (всё выше + Google Calendar, оплата, кабинет клиента) | +1–2 недели |
Сравнение методов блокировок
| Метод | Надёжность | Производительность | Сложность реализации |
|---|---|---|---|
| Пессимистичная блокировка | Высокая | Средняя | Низкая |
| Оптимистичная блокировка | Средняя | Высокая | Средняя |
Пессимистичная блокировка (SELECT FOR UPDATE) гарантирует отсутствие двойной записи даже при пиковых нагрузках. Оптимистичная блокировка (version column) подходит для сценариев с низкой конкуренцией, но требует обработки повторных попыток.
Типичные ошибки при проектировании
Часто клиенты просят добавить поле «свободные слоты» в таблицу, но это ведёт к аномалиям при параллельных транзакциях. Правильный подход — вычислять слоты на лету через алгоритм. Другая распространённая ошибка — игнорирование часовых поясов. Если специалист работает в одном часовом поясе, а клиент из другого, слоты должны отображаться в его локальном времени. Третья — отсутствие буфера между записями. Без него специалист опаздывает на 10–15 минут, что накапливается в течение дня.
Что входит в работу
- Документация: ER-диаграмма, описание API, инструкция по интеграции виджета.
- Доступы: репозиторий кода, тестовый стенд, панель администратора.
- Обучение: 2-часовая сессия для вашего администратора.
- Поддержка: 1 месяц гарантийного сопровождения после запуска.
Гарантируем отсутствие двойной записи и корректную работу при высоких нагрузках. Оцените ваш проект — свяжитесь с нами для консультации. Закажите расчёт — мы подберём оптимальную комплектацию под ваш бюджет и сроки.