Разработка платформы для продажи билетов (Ticketing)

Разработка тикетинговой платформы: где ломается продажа билетов

Продажа билетов — это короткое окно, в котором сходится всё: маркетинг приводит трафик на старт продаж, платёжный провайдер отвечает с задержкой, а зал на 5 000 мест разбирают за минуты. Именно здесь чаще всего ломаются самописные системы: пиковая нагрузка в первые секунды продаж выбивает базу, а двойное бронирование всплывает уже после оплаты, когда два человека держат один и тот же ряд.

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

Рассинхрон мест и оплат добавляет второй слой проблем: платёж прошёл, а место не закрепилось — или наоборот, бронь висит и блокирует зал, пока деньги не дойдут. Без фонового снятия просроченных броней и сверки статусов с платёжным провайдером зал «залипает», а поддержка вручную разбирает каждый случай. Возвраты, обмены и переносы на другой сеанс в такой схеме тоже ложатся на операторов.

Мы проектируем тикетинговые платформы так, чтобы эти узкие места закрывались на уровне архитектуры, а не героическими усилиями команды в день старта. Разбираем, как это устроено и какие решения снимают нагрузку до того, как она станет инцидентом.

Что даёт управляемая платформа продажи билетов

Управляемое бронирование решает главную проблему билетных систем — гонку за местом. Когда на один и тот же ряд одновременно приходят сотни запросов, место закрепляется за конкретной сессией на короткое окно и освобождается автоматически, если оплата не прошла. Это убирает двойные продажи и «зависшие» брони, из-за которых поддержка разбирает конфликтные заказы вручную.

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

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

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

Модели продажи билетов: сравнение подходов

Выбор модели — это не «какой движок возьмём», а то, как устроена посадка, сколько сущностей живёт в заказе и что происходит при возврате. Ошибка на этом уровне всплывает позже: переполненный зал, двойная продажа места или невозможность продать абонемент без переписывания схемы данных.

На практике площадки редко живут в одной модели: днём — сеансы с местами, вечером — свободная посадка на фестивале, плюс абонемент на сезон. Поэтому схему зала и логику посадки мы выносим в отдельный слой, а не «зашиваем» в билет. Тогда новая модель добавляется конфигурацией, а не переделкой ядра, и уже проданные заказы остаются валидными.

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

Как мы ведём разработку тикетинговой платформы

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

1. Аудит текущей продажи. Смотрим воронку от выбора события до выданного билета, считаем долю брошенных корзин и отказов на оплате, фиксируем пиковые окна — старт продаж на популярное событие, возвраты, переносы. На выходе — карта проблемных участков с приоритетами.
2. Схема данных. Проектируем модель событий, мест, тарифов, заказов и платежей так, чтобы места и цены не дублировались между залом и складом билетов. Заранее закладываем историю изменений: перенос события или возврат не должен ломать уже проданные билеты.
3. Удержание мест. Настраиваем временную блокировку выбранного места на время оформления: место недоступно другим покупателям, но освобождается автоматически, если оплата не прошла. Это убирает двойные продажи без ручного разбора конфликтов.
4. Интеграции оплат. Подключаем нужные способы оплаты и возвраты, синхронизируем статусы платежей с заказами, обрабатываем повторные попытки и отмены. Каждый платёж получает однозначный статус — бухгалтерия и поддержка видят одну картину.
5. Проверка под нагрузкой. Прогоняем сценарий старта продаж с расчётным числом одновременных покупателей, проверяем поведение удержания мест и очередей оплаты. Отдельно смотрим, что происходит при отказе внешнего платёжного сервиса.
6. Передача. Разворачиваем платформу, передаём доступы, схемы и регламенты, обучаем команду заказчика работе с админкой и разбору инцидентов.

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

Политики доступа, роли и регламенты возврата

Права в тикетинговой платформе описываются не «на словах», а матрицей ролей: кассир, старший смены, организатор, финансовый контролёр, администратор площадки. Каждой роли соответствует набор операций — продажа, бронь, возврат, обмен, сторно, выгрузка отчётов, — и эти правила живут в конфигурации, а не в инструкции на стене. Тогда новый сотрудник получает ровно тот объём доступа, который ему нужен, а не «как у коллеги».

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

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

Что фиксируем в конфигурации и документации:

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

Журнал операций неизменяем: запись нельзя отредактировать задним числом, только добавить корректирующую с ссылкой на исходную. Это то, что превращает спорный возврат из «разбирательства по памяти» в проверяемую историю с ответственным и основанием.

Кейс: как платформа выдержала старт продаж

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

Что было до

Под пиковой нагрузкой заказы оформлялись в среднем за 40-50 секунд, часть пользователей не дожидалась ответа и уходила. Доля двойных броней доходила до 3-4% от всех заказов — каждую такую ситуацию разбирали вручную, а возврат денег занимал дни. При старте продаж на популярное событие сервис переставал отвечать в течение первых минут.

Что изменили

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

Что стало после

Доля двойных броней упала до долей процента и держится на этом уровне. Среднее время оформления заказа сократилось до 8-12 секунд даже в момент старта продаж. Доля автоматических возвратов выросла до 90%+ — ручной разбор почти исчез. Платформа на базе Eventim выдержала старт продаж без падений и ручных вмешательств.

Чем отличается удержание места от брони на время?

Это два разных состояния места в схеме зала, и разница между ними — не терминологическая, а инженерная. Бронь на время — это короткая блокировка на период, пока клиент вводит платёжные данные: место помечается как занятое, но право на него ещё не подтверждено. Удержание места — более длительное состояние, при котором место закреплено за конкретным заказом и ждёт подтверждения оплаты уже после того, как платёж ушёл в обработку. Смешивать их в одной логике нельзя: если держать место часами на этапе ввода карты, зал «залипнет» и продажи встанут.

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

Освобождение места — это обратная операция, и она должна срабатывать автоматически по нескольким триггерам: истёк таймер, платёж отклонён, заказ отменён клиентом или оператором. Хорошо спроектированная платформа освобождает место не «когда-нибудь», а в ту же секунду, когда состояние заказа перестало быть активным, — иначе зал показывает занятые места, которые на самом деле свободны.

Подтверждение оплаты — единственное событие, которое переводит удержание в полноценный проданный билет. До него место числится зарезервированным, после — становится необратимо занятым, и освободить его можно только через возврат. Именно на этой границе чаще всего ломаются самописные решения: они либо отпускают место слишком рано, либо держат вечно.

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

Что делать, если продажа билетов уже работает

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

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

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

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

Обсудим вашу задачу по продаже билетов

Чтобы оценка была предметной, а не «средней по рынку», нам нужен минимум вводных: сколько событий и площадок, как продаёте сейчас, какие схемы бронирования и возврата, есть ли интеграции с платёжными провайдерами и входными турникетами, какие пиковые нагрузки ожидаете в старт продаж. Этого достаточно, чтобы вернуться с планом и оценкой по этапам, а не с одной цифрой «на всё».

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

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

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

Опишите задачу в свободной форме — вернёмся с оценкой и планом.