Создание сайта для покупки билетов в США, который прошёл Techstars: как мы его делали и что сделали не так
Время прочтения: 16 минут
В 2016 году мы занимались созданием сайта для покупки билетов на мероприятия — Хеллоутикетс. Сотрудничали тогда с новым зарубежным заказчиком, а позже стали партнёрами. Дальше вели проект вместе и прошли с ним акселератор Techstars.В статье поделимся решениями, которые использовали во время разработки и расскажем, сколько примерно может стоить создание похожего сервиса или веб-приложения.
Нужны ли сейчас билетные агрегаторы
Короткий ответ: да. Длинный ответ. По нашему мнению, билетные агрегаторы продолжат пользоваться спросом и дальше. Например, в больших городах России билеты на любое мероприятие можно купить онлайн. Но в городах поменьше с этим есть проблемы, например, у площадок может не быть своих сайтов. Поэтому покупать билеты на популярные мероприятия нужно в кассах города.Даже если агрегатор вам пока не нужен, наша история может оказаться полезнойБилетный агрегатор — это классический веб-сервис. Даже если вы не работаете с подобными продуктами, наш опыт всё равно можно переложить на похожие сервисы.
Контекст про Хеллоутикетс
В Америке проводится много культурных мероприятий: выставки, концерты, бейсбольные матчи, и часть туристов едет в страну только ради них. Но купить билеты на такие мероприятия онлайн было возможно не всегда. На некоторые из событий билеты продавались только в кассах в Америке, и для иностранных туристов это означало, что купить билет из своей страны невозможно. В 2016 году к нам обратился бизнесмен, который хотел изменить ситуацию и предложил разработать веб-сервис для покупки билетов на события в Америке. Он назвал этот сайт Хеллоутикетс. Агрегатор должен был собирать билеты на мероприятия в США от разных провайдеров и дать возможность иностранной аудитории купить их.Мы согласились взяться за работу и в итоге занимались проектом два года — реализовали frontend, backend и интеграции с билетными провайдерами.В основном подобные сервисы зарабатывают на комиссии с покупок. Например, Хеллоутикетс зарабатывал до $150 тысяч в месяц на пике, когда в день пользователи покупали от двадцати до восьмидесяти билетов. У Хеллоутикетс для разных стран есть несколько версий, в каждой из которых информация переведена на нужный язык и доступна оплата местной картой. Благодаря Хеллоутикетс, туристы из других стран получили возможность покупать билеты на спортивные матчи, концерты и выставки в США онлайн.
Так выглядел Хеллоутикетс, когда мы занимались сервисом
Сервис продолжает работать, только теперь там в основном продаются туры.Дальше расскажем, какие технологии мы использовали во время разработки и что хотели бы поменять, если взялись бы заново. А ещё дадим расчёты стоимости разработки подобного веб-сервиса.
Разработали всё на Golang
Ещё на ранних этапах разработки важно учитывать, как сервис будет развиваться, масштабироваться и какие фичи в нём появятся. И как следствие — подбирать технологию, которая будет решать задачи бизнеса.Как сделали тогда
В 2016 году, когда мы взялись за проект, Go только появился и был перспективной технологией, поэтому мы выбрали его. И в целом не разочаровались, но в процессе работы обнаружили и негативные стороны:- У нового языка ещё не было больших веб-фреймворков.
- В индустрии на тот момент было мало golang-разработчиков.
- И отсутствовала зрелая экосистема.
Сейчас поступили бы по-другому
Поняли, что лучше использовать более универсальные технологии. Так проще находить разработчиков и выбирать фреймворки. Для веб-приложений советуем: Python, Django, Node.js.
Если технология распространённая и проверенная, найти разработчиков будет легче
Выбрали микросервисы
Микросервисная архитектура состоит из независимых блоков, которые передают друг другу данные и формируют приложение. Особенность микросервисной архитектуры в том, что каждый блок существует автономно. Если появилась проблема в одной части, другие всё равно будут работать непрерывно. Но у микросервисов есть и обратная сторона. Например, увеличивается количество кода, который нужен для связи между блоками сервиса. Это значит, что поддерживать такой проект будет дороже.Как сделал и тогда
На первых этапах разработки проекта мы знали, что у сервиса будут интеграции, например, с провайдерами из США, чьи билеты мы будем размещать в агрегаторе. Поэтому сделали так, чтобы каждую интеграцию обслуживал отдельный микросервис. Думали, это поможет поддерживать проект в будущем, но ошиблись.Микросервисная архитектура полезна для больших и сложных продуктов, но если использовать такую архитектуру на старте — это только затянет разработку. Например, у наших инженеров треть дня уходила на поддержку самих микросервисов, а не на то, чтобы создавать продукт.Сейчас поступили бы по-другому
В начале разработки рекомендуем выбрать монолитную архитектуру — это облегчит поддержку. Не стоит усложнять всё раньше времени: чем дольше система остаётся простой, тем меньше ресурсов потребуется на её поддержку.
Взяли иллюстрацию из
Добавили систему безопасности
Мошенники могут использовать билетные агрегаторы для обналичивания денег с украденных карт. Схема выглядит так: мошенник покупает неименной билет с украденной карты на ближайшее событие — так больше шансов, что билет не аннулируют, — а затем перепродаёт его в другом месте за наличные.Потом владелец карты заявляет о том, что её украли, и банк отменяет платёж. Так у злоумышленника остаются наличные, а агрегатор вынужден вернуть деньги. Наша задача — уменьшить количество подобных ситуаций, а в идеале — вовсе их предотвратить. Для этого мы спроектировали антифрод-систему.Как сделали тогда
Владелец Хеллоутикетс уже работал в билетной индустрии, и поэтому знал схемы мошенничества. Так что узнали о них заранее и добавили систему безопасности ещё в начале разработки. Основной целью системы было классифицировать мошеннические операции и блокировать их, чтобы злоумышленники не могли оплачивать билеты с ворованных карт. Наша система умела обнаруживать ворованные карты по заранее обозначенным критериям, вот часть из них:Позже мы также внедрили 3D-Secure аутентификацию при оплате, и не принимали карты стран, где её не поддерживают
Сейчас оставили бы тот же подход
Мы также заранее изучили бы бизнес-процессы с экспертом отрасли, проанализировали риски, описали критерии для подозрительных операций и внедрили бы систему безопасности в продукт как можно раньше.Обеспечили единообразие данных
В больших веб-приложениях и агрегаторах обычно собираются данные от разных провайдеров. Эта информация может выглядеть неоднородно. Поэтому, прежде чем выводить данные пользователям, нужно привести их к единой структуре. Вот пример из Хеллоутикетс. В агрегатор поступала информация о местах для зрителей на стадионе. Обычно места разделяются на секторы и уровни. И вот один поставщик данных может назвать секцию «амфитеатр» полным словом «amphitheatre», другой — «amph», а третий — «lawn». Это может запутать пользователей, поэтому важно, чтобы у данных был единый формат.Как сделали тогда
Разработали систему, которая будет унифицировать данные с билетов от разных поставщиков. Так места с пометкой «amphitheatre» или «amph» не разобьются на две группы, а будут в одной.Потом мы добавляли данные с билетов на виртуальные карты площадок, где будет проводиться мероприятие. Часть этих площадок предоставляли поставщики, часть нам помог создавать подрядчик: — сервис, который делал для нас карты площадок.В итоге у нас получилось показывать информацию от разных провайдеров на одной карте. Благодаря такой системе, пользователи смотрели цены за одно и то же место от разных провайдеров и выбирали лучшее предложение.
Интерфейс Хеллоутикетс: схема Мэдисон-сквер-гарден, арены в Нью-Йорке
Сейчас бы выбрали тот же путь
изучили бы бизнес-процессы и выделили в них места, где потенциально могут быть разнородные данные. А потом структурировали бы их с помощью автоматической системы, интерфейса админки для операторов или объединили бы несколько вариантов решений. Написали бы скрипты и автоматизировали процессы там, где это возможно.Сколько стоит агрегатор
Разработка подобного проекта с нуля займёт от шести до девяти месяцев. На зарплату команде нужно заложить примерно 2,3 млн ₽ в месяц:- Два фронтенд-разработчика — 800 000 ₽
- Два бэкенд-разработчика — 800 000 ₽
- UI/UX-дизайнер — 300 000 ₽
- QA/QC — 250 000 ₽
Ознакомиться с экспертизой и другими проектами студии КОД9 можно на .
