Зазначимо: коли стартують продажі на концерт популярної групи, за перші 30 секунд сервер отримує до 10 000 запитів на бронювання. Система повинна атомарно утримати вибрані місця, не допустивши подвійних продажів, і одночасно показувати актуальну схему залу тисячам користувачів. Без продуманої архітектури — падіння сервера, втрата виручки, негативні відгуки. Ми розробили систему бронювання, яка витримує такі навантаження: використовуємо атомарні транзакції PostgreSQL, кешування в Redis 7, синхронізацію через WebSocket та інтерактивну SVG-схему на React 18. За роки практики ми впровадили таке рішення для 50+ заходів — від 200 до 50 000 місць. Наші клієнти відзначають зниження витрат на інфраструктуру на 35% та окупність проєкту за 2-3 заходи (економія до $2.2k–3.2k. за один захід).
Основні проблеми та їх вирішення
При бронюванні місць виникають три ключові проблеми:
- Подвійні продажі. Два клієнти одночасно обирають одне місце. Рішення: атомарні транзакції з утриманням (hold) на 10 хвилин. Якщо місце вже зайняте, транзакція відкочується, клієнт бачить помилку без перезавантаження сторінки.
- Пікове навантаження. Тисячі одночасних запитів при старті продажів. Рішення: кешування схеми залу в Redis, асинхронне оновлення статусів, WebSocket для real-time синхронізації. Це знижує навантаження на базу даних у 10 разів.
- Складна схема залу. SVG з координатами місць, правильне відображення та клікабельність. Використовуємо React з хуком useRef для рендерингу, мемоізацію через React.memo та useCallback. Схема завантажується за 50–100 мс навіть для залів з 5000 місць.
Як уникнути подвійних продажів?
У момент вибору місць клієнтом вони тимчасово блокуються — до завершення оплати або закінчення таймера. Приклад реалізації на Python з PostgreSQL:
Приклад реалізації утримання місць
HOLD_TTL_SECONDS = 600 # 10 хвилин
def hold_seats(seat_ids: list[int], session_id: str) -> bool:
with db.transaction():
# Атомарно перевірити та заблокувати
result = db.execute("""
UPDATE seats
SET status = 'held', held_by = %(session)s, held_until = NOW() + INTERVAL '10 minutes'
WHERE id = ANY(%(ids)s) AND status = 'available'
RETURNING id
""", {'ids': seat_ids, 'session': session_id})
held_count = len(result)
if held_count < len(seat_ids):
# Не всі місця доступні — відкотити транзакцію
raise db.Rollback("Some seats are no longer available")
return TrueЗвільнення прострочених hold-ів — фоновий процес, запускається кожну хвилину:
UPDATE seats SET status = 'available', held_by = NULL, held_until = NULL WHERE status = 'held' AND held_until < NOW(); Детальніше про атомарні транзакції PostgreSQL.
Схема залу в реальному часі
Візуальна схема залу (seat map) рендериться на SVG. Дані про місця запитуються з бекенду:
{
"sections": [
{
"id": 1,
"name": "Партер",
"rows": [
{
"label": "A",
"seats": [
{
"id": 1001,
"number": "1",
"x": 100,
"y": 200,
"status": "available",
"price": 2500
},
{
"id": 1002,
"number": "2",
"x": 130,
"y": 200,
"status": "sold",
"price": 2500
}
]
}
]
}
]
}Клієнт клікає на місце, воно підсвічується, додається в кошик. При спробі додати вже зайняте — показується помилка без перезавантаження сторінки (WebSocket або polling кожні 5 секунд). Завдяки кешуванню в Redis схема завантажується за 50-100 мс навіть для залів з 5000 місць.
Порада щодо оптимізації схеми: використовуйте virtual DOM та мемоізацію компонентів, щоб уникнути зайвих рендерів при швидкому кліку по місцях. У React — React.memo та useCallback.
Чому наша система витримує піки?
| Критерій | Наша система | Типове рішення |
|---|---|---|
| Утримання місць | Атомарні транзакції з TTL | Тільки статуси в БД |
| Real-time | WebSocket + Redis | Polling (5-10 сек) |
| Схема залу | SVG з координатами | Зображення без кліку |
| Хвилі продажів | Автоматичні тири з квотою | Ручне перемикання |
Додатково ми провели навантажувальне тестування: система обробляє до 10 000 одночасних запитів при старті продажів — у 3 рази швидше типових аналогів. Відсоток покинутих кошиків знижується на 30% завдяки плавному блокуванню та real-time оновленням. Економія на інфраструктурі становить близько $1.4k–1.9k. на місяць порівняно з традиційними рішеннями.
Порівняння продуктивності:
| Метрика | Наша система | Типовий аналог |
|---|---|---|
| Час відповіді при піку (95 перцентиль) | 200 мс | 1.5 с |
| Втрачені бронювання (через конфлікти) | 0.01% | 2% |
| Час завантаження схеми залу | 80 мс | 500 мс |
Процес роботи
- Аналітика: вивчаємо схему залу, вимоги до хвиль продажів, способи оплати.
- Проектування: обираємо стек (PostgreSQL, Redis, React), проектуємо модель даних.
- Розробка: реалізуємо API, схему залу, утримання місць, інтеграцію з платіжним шлюзом.
- Тестування: навантажувальне тестування (наприклад, 1000 одночасних бронювань), перевірка консистентності.
- Деплой: розгортання на вашому хостингу або в хмарі (Vercel, AWS).
- Підтримка: оновлення, моніторинг, резервне копіювання.
Що входить в роботу
- Модель даних (таблиці events, seat_categories, seats, ticket_bookings).
- API для бронювання, утримання, скасування.
- Інтерактивна схема залу (SVG) з real-time оновленнями.
- Електронні квитки з QR-кодом (PDF, Apple Wallet, Google Pay).
- Інтеграція з платіжними системами (опціонально).
- Документація та навчання персоналу.
Терміни
- Базова версія (без схеми залу, проста нумерація місць, оплата онлайн) — від 10 робочих днів.
- Повна версія (схема залу, real-time, цінові тири, електронні квитки) — від 16 робочих днів.
Вартість розраховується індивідуально після аудиту вашого проєкту. Щоб отримати точну оцінку, зв'яжіться з нами — надішлемо комерційну пропозицію протягом доби. Замовте аудит, щоб обговорити деталі.
Типові помилки при реалізації
- Ігнорування механізму утримання місць → подвійні продажі.
- Відсутність фонового звільнення прострочених hold-ів → місця «зависають».
- Погана оптимізація запитів до схеми залу → довге завантаження.
- Відсутність кешування → падіння при піку.
Наша команда гарантує, що цих помилок не буде. Отримайте консультацію, щоб обговорити ваш проєкт. Зв'яжіться з нами для аудиту — ми підготуємо індивідуальну пропозицію.
