Эта статья о закулисье рынка продажи билетов на события всех видов написана для специалистов, вовлеченных в организацию продажи билетов через интернет. В ней описываются несколько решений ключевой проблемы: как показать покупателю билетов актуальную информацию о местах и ценах в ситуации, когда организатор события может произвольно менять её в любое время, а в продажу билетов вовлечено множество систем. Понятно, что покупателю всегда нужно видеть актуальное наличие мест и последние цены «сразу» после изменения организатором. Рассмотрим, как это «сразу» делается сейчас, или может делаться в будущем.
Важное замечание: во всех описанных ниже решениях продажа билетов по устаревшим, неактуальным ценам невозможна, так как большинство профессиональных билетных систем проверяет цены на этапе создания (оформления) заказа. Кроме этого, для всех решений не рассматривается несовершенство сети передачи данных, так как сбои в сети негативно влияют на любое из них.
Дано:
Организатор создал событие в своей билетной системе, и открыл продажу билетов для агентов, использующих множество других систем, связанных через API-шлюзы. В этом случае, система организатора (далее система-источник) является источником информации о местах, ценах, билетах для всех других систем, взаимодействующих с ней по API (далее агентские системы). Организатор вправе изменять ценовые категории, открывать и закрывать продажу определенных мест в любое время. И многие организаторы пользуются этим правом довольно часто. Чтобы на сайтах билетных агентов покупатели видели актуальные места и цены, необходимо, чтобы изменения, внесенные организатором, как можно скорее появлялись в агентских системах. Здесь существует проблема актуальности информации и разные способы её решения, каждый со своими плюсами и минусами.
Решение 1: опрос (polling)
Polling — это метод получения информации от системы-источника путем периодического опроса. Это наиболее плохое, и в то же время наиболее распространенное решение. Думаю, что его популярность вызвана простотой разработки. Достаточно раз в час, в минуту или в секунду опрашивать систему-источник, получать все данные и обновлять их у себя в агентской системе. Если делать это раз в минуту, то уже через эту минуту сделанные организатором изменения достигнут агентской системы (если в системе-источнике не используется кэш) и будут продемонстрированы покупателям билетов. Главный минус – гигантское число запросов от множества агентских систем и значительный объем передаваемых данных. Большинство современных систем-источников защищается от этого с помощью кэшей разных уровней, обновляемых, например, раз в час. В итоге, нередки ситуации, когда агентская система «долбит» ежеминутными запросами систему-источник у которой стоит кэш, обновляемый каждый час. В этом случае агентская система получает неактуальные данные из кэша, а ежеминутный опрос - это пустопорожнее расходование серверных мощностей и бессмысленная утилизация каналов связи.
Негативный эффект polling’a увеличивается, если продаются билеты, например, на футбольные матчи на многотысячных стадионах, так как на запросы множества агентов необходимо «отгружать» большие объемы данных о десятках тысяч мест.
Решение 2: запрос по требованию (on demand)
В отличие от polling’a запрос on demand направляется в систему-источник только в случае, если покупатель открыл схему зала или стадиона, и собирается приобрести билеты. Запрос отправляется «по требованию» реального покупателя. Если покупателей нет, то и запросов тоже нет. Такое решение лучше polling’a, но имеет свои минусы: для запроса информации и обновления данных стандартными средствами в агентской системе требуется время, так как передается весь объем информации, а не только изменения (хотя это зависит от конкретной системы-источника и его API). Соответственно, после изменений, у одного или нескольких покупателей за счет обращения в систему-источник схема с местами и ценами может открываться дольше обычного, или даже отобразится без учета этих изменений (зависит от реализации в агентской системе). Тогда как для последующих покупателей будут загружены актуальные данные из агентской системы . Другой минус: вместо реальных покупателей по сайтам билетных агентов «ходят боты и парсеры», которые вызывают к жизни множество запросов в систему-источник.
Решение 3: передача только измененной информации
Система-источник может накапливать изменения, внесенные организаторами, и отдавать только их, а не полный объем данных. При таком решении агентские системы имеют возможность получить только изменения и сохранить их у себя. Главный минус этого решения сегодня: сложность работы с современными комплексными и сильно взаимосвязанными данными, сложность современных процессингов, обрабатывающих эти данные. Система работы с обновлениями вызывает экспоненциальный рост сложности всех систем. Плюсом этого решения является меньший объем передаваемых данных. Надо отметить, что это решение может совмещаться с polling’ом и запросами по требованию.
Решение 4: отправка уведомлений (notifications)
Лучшим решением на сегодня, является отправка уведомлений из системы-источника в агентские системы. Отправка происходит в момент сохранения Организатором изменений в системе-источнике, а уведомление содержит информацию о внесенных изменениях. На основе этой информации агентская система может сразу запросить измененные данные стандартными способами и сохранить эти изменения у себя. Например, если организатор изменил цены в одном или нескольких сеансах, то в агентскую систему придет уведомление со списком измененных сеансов, и эта система может сразу получить и обновить у себя только эти сеансы, используя стандартные запросы API.
Плюсы такого решения:
- Не нужно создавать систему учета обновлений и связанные с ней новые запросы в API системы-источника. Узнав из уведомления об измененных объектах, можно запросить их уже существующими (стандартными) командами API.
- Не нужно постоянно опрашивать систему-источник, или ждать покупателя билетов, который инициирует запрос по требованию, не нужно реагировать на «боты и парсеры». Как только в системе-источнике произойдет изменение, в агентские системы будут направлены соответствующие уведомления, и они смогут обновить изменившиеся объекты на своей стороне.
- Передача только обновленных объектов – это меньший объем данных, чем при получении всех объектов, связанных с событиями и сеансами организатора.
В отличие от других решений, отправка уведомлений базируется на действиях, которые можно и нужно предпринять в момент сохранения внесенных организатором изменений. Таким образом, сам организатор является триггером, запускающим процесс актуализации данных во всех системах. При таком раскладе, покупатели билетов увидят актуальные места и цены на схеме стадиона практически сразу после внесения этих изменений организатором.
Как создать систему уведомлений?
Модуль для отправки уведомлений необходимо создавать в системе-источнике. Триггером для отправки может быть практически любое событие в билетной системе: обновления данных сеанса (места, цены, настройки), изменение времени начала сеанса, времени начала и окончания продаж и т.п. Хорошо, если у агента будет возможность самостоятельно выбрать триггеры для отправки уведомлений в его систему. Тогда агент может настроить работу с уведомлениями в зависимости от своих целей и задач.
В платформе BIL24 существует система уведомлений, где в настоящий момент реализованы триггеры: Заказ оплачен, Заказ отменен, Билет возвращен. Агент самостоятельно конфигурирет систему во вкладке Уведомления приложения Менеджер. В будущем планируется добавить триггеры для изменения цен, доступности мест, параметров сеансов. Однако, для рынка в целом необходимо, чтобы уведомления приходили от многих популярных билетных систем, являющихся первоисточником информации о событиях. В случае реализации подобного решения хотя бы в основных билетных системах и платформах, проблема актуальности информации для покупателей билетов будет эффективно решена.