Создание сайта для покупки билетов в США, который прошёл 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 можно на .
