Агрегатор билетов в США, который прошёл Techstars: как мы его делали и что сделали не так

Привет, на связи Эд Хорьков из КОД9. Несколько лет назад мы разработали для зарубежного заказчика билетный агрегатор Hellotickets. Позже стали партнёрами проекта и прошли с ним акселератор Techstars. В статье хочу рассказать, какие технологии мы использовали, и дать несколько советов тем, кто собирается создавать похожие веб-сервисы.

Hellotickets — это агрегатор билетов на события в США для туристов

Мы разработали всё на Go, но сейчас взяли бы другую технологию

Сделали микросервисы, но сейчас бы выбрали монолит

Добавили анти-фрод системы — сейчас бы тоже задумались о них

Делали данные однородными — сейчас сделали бы так же

На запуск аналогичного проекта уйдёт примерно полгода

Кратко: что важно знать о разработке билетных агрегаторов

В США приезжает много туристов из Европы и Латинской Америки, и часть из них хотят сходить на бродвейский мюзикл или бейсбольный матч. Но билеты на такие события неудобно, а иногда и невозможно купить из-за границы.

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

Основатель Hellotickets обратился к нам в 2016 году, и мы занимались проектом вплоть до 2018-го. Создали весь веб-сервис целиком — занимались фронтендом, бэкендом, интеграциями и взаимодействиями с билетными провайдерами.

На пике средняя цена за билеты была в районе $100, средний чек составлял $200, в день совершалось от 20 до 80 покупок, а месячная выручка составляла $100–150 тысяч.

К лету 2023-го сервис несколько раз поменял модель, но всё ещё работает — сейчас там в основном продают туры:

👉 Hellotickets

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

Как мы сделали в Hellotickets. Мы занимались разработкой сервиса с 2016-го по 2018-й и выбрали Go в качестве основной технологии. Тогда он только появился и был на слуху — новый, быстрый и перспективный.

Golang действительно оказался быстрым и надёжным, но по мере работы с ним открылись и отрицательные стороны:

Все эти причины в итоге негативно повлияли на скорость разработки. Например, мы написали на Go весь бэкенд, но в итоге всё равно пришлось писать прослойку Backend-for-Frontend на Python.

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

Как бы сделали теперь. Думаю, мы бы взяли более универсальную и популярную технологию, вокруг которой уже есть большое комьюнити. Это значит, будет проще выбрать фреймворк и искать разработчиков. Для веб-сервиса я советую Python и Django, Node.js.

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

Ещё одно преимущество микросервисов — каждый блок можно заменить или переделать отдельно от других, и качество работы проекта не пострадает.

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

Как мы сделали в Hellotickets. Мы понимали, что у агрегатора будет много интеграций — например, с разными билетными провайдерами из США. Поэтому решили, что каждую интеграцию будет обслуживать отдельный микросервис.

Это было решение с оглядкой на будущее, но сейчас я уверен, что это было ошибкой. Микросервисная архитектура оправдана в большом продукте, но на начальном этапе разработки только создаёт дополнительные трудности. Например, у нас на старте было 2–3 инженера и до 30% их времени уходило на поддержку микросервисной инфраструктуры, а не на реализацию бизнес-логики.

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

В билетных агрегаторах всегда есть риск мошеннических схем, поэтому анти-фрод системы важно запланировать заранее.

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

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

Как мы сделали в Hellotickets. Заказчик уже работал на билетном рынке и знал часть рисков и схем, поэтому мы сразу продумали антифрод-системы.

Ключевая задача конкретно для Hellotickets — научиться идентифицировать ворованные карточки. Вот несколько прокси-метрик, на которые мы обращали внимание, чтобы выделять такие карты:

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

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

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

Как мы сделали в Hellotickets. Чтобы мэтчить между собой билеты разных провайдеров, мы придумали систему унификации данных. Поэтому и билеты с пометкой amphitheatre, и билеты с пометкой amph в нашей системе снова назывались одинаково.

Затем мы накладывали информацию с билетов на карты площадок. Часть из них предоставили поставщики билетов, а для некоторых площадок мы создали новые цифровые модели силами подрядчика:

👉 Seats — сервис, который создавал для нас карты площадок

Со временем мы научились корректно показывать данные разных провайдеров на одной карте площадки. Это позволило предлагать пользователю несколько вариантов цены за одно и то же место, чтобы он мог выбрать самую выгодную.

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

В зависимости от сложности задачи на разработку уйдёт от 6 до 9 месяцев — возможно и дольше. Команда, которая создаст веб-сервис, стоит примерно 2,3 млн ₽ в месяц:

Соответственно, если проект займёт полгода, он обойдётся в 13,8 млн ₽:

6 месяцев × 2,3 млн ₽ = 13,8 млн ₽

👉 Выбирайте технологию, которая позволит решать бизнес-задачи, а ещё будет достаточно популярной, чтобы можно было легко найти разработчиков. Для веб-сервисов советую Python и Django, Node.js.

👉 Создавайте монолит — в начале разработки это всегда практичнее. Нет смысла переходить на микросервисы до тех пор, пока ваша система не станет слишком сложной, чтобы поддерживать её на монолите.

👉 Продумайте анти-фрод системы. Стоит изучить бизнес-логику вместе с инсайдером рынка, чтобы определить все места, где могут появиться уязвимости. Главная проблема в Hellotickets — на билетах обналичивали деньги с ворованных карт.

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

👉 На запуск веб-сервиса в духе Hellotickets в 2023-м уйдёт от 6 месяцев. Команда, которая справится с запуском, обойдётся в 2,3 млн ₽ в месяц.

Делимся другими кейсами:

❤ Важное про разработку дейтинговых приложений

⌚ Рассказываем, как делать приложения для носимых устройств

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