Основная архитектура
Система следует микросервисной архитектуре, где каждый домен обрабатывается независимым сервисом: Search, Booking, Inventory, Pricing, Payment, Notification и Airline Integration.
Поиск и интеграция с авиакомпаниями
- Search Service агрегирует результаты от нескольких авиакомпаний через единый API gateway
- API сторонних сервисов оборачиваются с помощью паттерна Adapter для нормализации разнородных форматов данных
- Результаты поиска кэшируются (например, Redis) с коротким TTL для баланса между актуальностью и производительностью
Инвентарь мест и управление конкурентностью
Предотвращение овербукинга критично. Система использует двухфазную модель резервирования мест:
- Фаза 1 – Hold: Место временно блокируется с помощью distributed locks (например, Redis
SETNX) или optimistic locking на уровне базы данных с коротким TTL (например, 10 минут)
- Фаза 2 – Confirm: Место окончательно резервируется только после успешной оплаты
Это гарантирует, что два пользователя не смогут забронировать одно и то же место одновременно.
Pricing Engine
- Отдельный Pricing Service применяет динамические правила на основе спроса, времени до вылета и класса места
- Правила хранятся вне сервиса, что позволяет обновлять их без передеплоя
Обработка платежей
- Платежи обрабатываются через PCI-compliant шлюз стороннего провайдера (например, Stripe)
- Паттерн Saga или two-phase commit гарантирует консистентность между подтверждением платежа и резервированием места
Жизненный цикл бронирования
Search → Hold Seat → Process Payment → Confirm Booking → Issue Ticket
↓ (failure)
Release Hold → Notify User
Отмены и уведомления
- Отмены запускают воркфлоу возврата средств на основе политик конкретной авиакомпании
- Event-driven подход (например, Kafka) публикует изменения состояния бронирования в Notification Service, доставляя обновления по email/SMS на каждом этапе жизненного цикла