АвиабронированиеVue 3 · Nuxt8 лет домена

TravelShop — система поиска
и бронирования авиабилетов

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

обложка кейса · крупный скриншот продукта
экран поиска и выдачи рейсов
−60%ошибок при бронировании
+25%производительности
−40%багов в интерфейсе
+35%к скорости разработки
Задача

Домен,
где ошибка
стоит дорого.

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

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

Подход

Что я сделал.

Не «латал баги», а менял основания: архитектуру, валидацию, кеширование и компонентную базу.

01

Масштабируемая архитектура

Переписал ядро: чёткое разделение ответственности, предсказуемое состояние на Pinia, изоляция бизнес-правил тарификации от UI.

архитектураPinia
02

Система валидации

Единый слой валидации данных пассажиров вместо проверок, разбросанных по формам. Ошибки ловятся раньше и в одном месте.

валидацияформы
03

Кеширование поиска

Кеширование тяжёлых поисковых запросов с контролем актуальности — меньше нагрузки и заметно быстрее отклик.

кешperformance
04

Библиотека компонентов

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

UI-kita11y
экран выдачи рейсов · фильтры и тарифы
форма данных пассажиров
шаг оплаты и подтверждения
Результат

Цифры, за которыми
стоят решения.

Каждая метрика — следствие конкретного инженерного изменения, а не общее «стало лучше».

  1. −60%
    Ошибок при бронировании

    Снизил число ошибок за счёт единой системы валидации данных о пассажирах.

  2. +25%
    Производительности

    Ускорил систему за счёт кеширования тяжёлых поисковых запросов.

  3. −40%
    Багов в интерфейсе

    Сократил баги за счёт библиотеки переиспользуемых компонентов.

  4. +35%
    К скорости разработки

    Ускорил добавление функций за счёт масштабируемой архитектуры.

«Сложный домен не прощает временных решений. Здесь архитектура — это не роскошь, а условие, при котором продукт вообще можно развивать.»

— Данил Лисин, о работе над TravelShop
Следующий шаг

Нужен такой же результат?

Опишите задачу — обсудим, какие метрики реально сдвинуть и за какой срок. Работаю по NDA.