Проблема подвійних бронювань та застарілих даних — часта головний біль при запуску онлайн-запису. Календар показує невірні слоти, користувачі втрачають час, бізнес втрачає клієнтів. Ми вирішуємо ці завдання за допомогою версіонування рядків та WebSocket-інвалідації. Наша система бронювання онлайн з інтерактивним календарем доступності дозволяє керувати слотами, синхронізувати ресурси (React, TanStack Query, WebSocket), та забезпечує бронювання спеціалістів — це ідеальний календар для запису. За 40+ проєктів для клінік, салонів і сервісів ми накопичили бібліотеку готових рішень: від оптимістичних блокувань до агрегованого завантаження місяця одним запитом. Нижче розберемо ключові проблеми, їх рішення та процес розробки.
Проблеми, які ми вирішуємо
Race condition при бронюванні. Коли два користувачі одночасно намагаються зайняти останній слот. Без атомарного оновлення обидва отримають підтвердження. Ми використовуємо версіонування рядків та оптимістичні блокування. Атомарні операції в базе даних гарантують цілісність.
Stale data на клієнті. Календар показує зайняті слоти як вільні. Рішення — потокова інвалідація кешу через WebSocket і повторне завантаження при поверненні на сторінку. В одному проєкті для мережі клінік ми зменшили завантаження місяця з 30 окремих запитів до одного агрегованого, що скоротило час рендерингу на 70%.
N+1 запити при завантаженні місяця. Замість 30 запитів (по одному на день) ми завантажуємо агреговані дані одним запитом на місяць, а часові слоти — окремо при виборі дня. Це типова проблема, яку вирішує правильна стратегія кешування.
Як уникнути подвійних бронювань?
Використовуємо оптимістичне блокування: слот має поле version. При спробі бронювання робимо UPDATE з перевіркою version = ?. Якщо зачеплено 0 рядків — слот уже зайнятий, повертаємо помилку. Для групових слотів перевіряємо remaining > 0 і атомарно зменшуємо лічильник. Оптимістичне блокування дозволяє обробляти в 3 рази більше запитів на секунду порівняно з песимістичним блокуванням (SELECT FOR UPDATE). При цьому в 99.9% випадків колізія не виникає. Оптимістичне блокування краще за песимістичне у 3 рази за продуктивністю.
Що робити з кешуванням при високому навантаженні?
Застосовуємо комбінацію:
- Інвалідація по WebSocket при змінах.
- Stale-while-revalidate: поки триває оновлення, показуємо старі дані.
- Збільшуємо
staleTimeдо 5 хвилин для малоактивних днів.
Докладніше про стратегію кешування
Для оптимізації ми використовуємо stale-while-revalidate та інвалідацію по WebSocket. Залежно від навантаження можна адаптувати TTL.
У проєкті з 15 спеціалістами і 300 слотами на день ми налаштували TTL кешу на місяць у 60 секунд, що дозволило знизити навантаження на сервер у 4 рази без втрати актуальності даних. Кешування помилок (наприклад, 500-х) також допомагає уникнути каскадних збоїв. Агреговане завантаження в 30 разів ефективніше за традиційний підхід.
Порівняння підходів до блокування слотів
| Підхід | Надійність | Продуктивність | Складність реалізації |
|---|---|---|---|
| Оптимістичне блокування | ★★★★☆ | ★★★★★ | ★★★☆☆ |
| Pessimistic lock (SELECT FOR UPDATE) | ★★★★★ | ★★☆☆☆ | ★★☆☆☆ |
| Черга підтверджень (Redis + worker) | ★★★★☆ | ★★★★☆ | ★★★★★ |
Оптимістичне блокування — золота середина: висока швидкість при стандартних сценаріях і прийнятний захист від колізій.
Вплив розміру кешу на швидкість відгуку
| TTL кешу (сек) | Середній час завантаження (мс) | Навантаження на сервер (RPS) | Актуальність даних |
|---|---|---|---|
| 30 | 120 | 200 | Висока |
| 60 | 180 | 100 | Середня |
| 120 | 250 | 50 | Низька |
Для бронювань оптимально 60–120 секунд — баланс між швидкістю та свіжістю даних.
Процес роботи
- Аналітика: збираємо вимоги: кількість ресурсів, типи слотів, правила відображення (інтервали, крок, буфери).
- Проектування: схема бази даних, API (REST + WebSocket), компоненти React.
- Реалізація: код, модульні тести, інтеграційні тести на критичні сценарії.
- Тестування: навантажувальне (1000 одночасних броней) і ручне (різні часові пояси, перехід через межу доби).
- Деплой: на ваш сервер з документацією.
Що входить до роботи
- Вихідний код календаря та API (репозиторій Git).
- Документація: схема API, інструкція з розгортання, опис логіки доступності.
- Доступ до демо-стенду на час розробки.
- Навчання ваших інженерів (1 сесія до 2 годин).
- Місяць технічної підтримки після деплою.
Строки та вартість
Базова версія календаря з API та компонентом — від 4 до 6 робочих днів. Вартість розраховується індивідуально залежно від складності: кількості ресурсів, типів слотів, необхідності синхронізації із зовнішніми системами. Ми працюємо понад 5 років і виконали 40+ проєктів з бронювання. Отримайте консультацію — зв'яжіться з нами для оцінки вашого проєкту. Замовте розробку календаря доступності сьогодні.
Типові помилки, яких ми не допускаємо
- Ігнорування часових поясів. Зберігаємо все в UTC, на клієнті перетворюємо.
- Занадто довгий TTL кешу. Для бронювань оптимально 60–120 секунд.
- Відсутність візуального розділення станів. Слот може бути: доступний, зайнятий, заблокований, недоступний за часом, повний. Кожен — свій колір.