Архитектура платформы vitrip.store

Версия: 1.1
Дата: 19.04.2026
Статус: Готов к обсуждению

Обзор проекта

vitrip.store — это платформа агрегации отельных данных с уникальным конструктором туров и собственным Partner API для B2B продаж.

Бизнес-модель

Входящий поток данных: Агрегируем отели от множества поставщиков (Stuba, HomeToGo, RateHawk), нормализуем в единую базу, обогащаем собственной логикой.

Исходящие каналы:

• B2C сайт — турагенты ищут отели, бронируют, собирают программы туров
• B2B API — внешние компании интегрируются с нашими данными через Partner API

Уникальная ценность: Не просто каталог отелей, а конструктор программ туров с подтяжкой цен в реальном времени и генерацией PDF для клиентов.

Архитектурные принципы

1. Горизонтальное масштабирование — каждый компонент может увеличиваться независимо
2. Разделение ответственности — каждый сервис решает одну задачу
3. Кеширование как основа — 90%+ запросов обслуживается из Redis
4. API-first подход — сайт использует те же API что и внешние партнёры
5. Отказоустойчивость — падение одного компонента не роняет систему

Архитектура (6 слоев)

Схема архитектуры: См. диаграмму vitrip_architecture_layers.jpg — интерактивная схема всех слоев с возможностью детального изучения каждого компонента.

Поставщики → Приём и обработка → Хранение → Бизнес-логика → API → Клиенты

1. Suppliers (Поставщики данных)

Цель: Получение сырых данных от различных источников

Компоненты:

• Stuba — XML/FTP массовые выгрузки отелей
• HomeToGo — GraphQL API для поиска и цен
• Others — будущие поставщики через REST/XML

Принцип: Для каждого поставщика — отдельный адаптер. Ядро системы не подстраивается под форматы поставщиков.

2. Ingestion layer (Слой приёма и обработки)

Цель: Нормализация разнородных данных в единый формат

Компоненты:

• Message queue (NATS → Kafka) — асинхронная обработка больших объёмов
• Parsers (Rust) — парсинг XML, валидация, нормализация данных
• Matcher (Rust) — нечёткий поиск дубликатов отелей между поставщиками

Ключевая задача: Один отель от трёх поставщиков должен стать одной записью в системе с объединёнными данными.

3. Storage (Слой хранения)

Цель: Надёжное хранение мастер-данных и быстрый доступ к часто запрашиваемой информации

Компоненты:

• PostgreSQL — отели, контент, бронирования, агенты (см. детальную схему в reference/)
• Redis — цены, доступность, результаты поиска (TTL 5-30 минут)

Принцип разделения: PostgreSQL для стабильных данных, Redis для volatile данных с коротким жизненным циклом.

4. Business services (Бизнес-сервисы)

Цель: Реализация бизнес-логики через микросервисы

Технологии: Go + gRPC (межсервисное взаимодействие)

Сервисы:

• Search — поиск отелей по параметрам, фильтры, ранжирование
• Pricing — расчёт наценок, конвертация валют, комиссии агентов
• Booking — создание, подтверждение, отмена бронирований
• Tour Builder — конструктор программ туров, генерация PDF

5. API layer (Слой API)

Цель: Единая точка доступа к системе для всех клиентов

Компоненты:

• API Gateway — маршрутизация, аутентификация, rate limiting, логирование
• Partner API — REST API для B2B клиентов с документацией и sandbox

Принцип: Веб-сайт и внешние партнёры используют одни и те же API. Одна логика для всех.

6. Clients (Клиенты)

Цель: Пользовательские интерфейсы для разных типов клиентов

Компоненты:

• Website (React/Next.js) — интерфейс для турагентов
• Partners — B2B интеграции через Partner API

Технологический стек

Слой	Технология	Обоснование
Business services	Go	I/O-интенсивные задачи, горутины, простота разработки
Data processing	Rust	CPU-интенсивные задачи, обработка больших объёмов
Database	PostgreSQL	Надёжность, JSONB, ltree для иерархий, PostGIS
Cache	Redis	In-memory, TTL, pub/sub для инвалидации
Message queue	NATS → Kafka	Асинхронность, гарантированная доставка
API Gateway	Traefik	Маршрутизация, middleware, интеграция с K8s
Frontend	React/Next.js	SSR, большая экосистема, TypeScript
Infrastructure	Docker + Kubernetes	Контейнеризация, горизонтальное масштабирование
Monitoring	Prometheus + Grafana	Метрики, дашборды, алертинг

Потоки данных

Схема потоков данных: См. диаграмму vitrip_data_flows.jpg — детальная схема трёх основных потоков с кешированием и обработкой ошибок.

Поток обновления данных (от поставщиков)

Supplier API → Message Queue → Parser → Database/Cache → API Gateway → Clients

Асинхронная обработка обновлений через очереди сообщений для высокой пропускной способности.

Поток пользовательских запросов

Client → API Gateway → Business Service → Cache (hit) → Client
                                      → Database (miss) → Cache → Client

85-95% запросов обслуживается из Redis кеша, остальные попадают в PostgreSQL с последующим кешированием.

Поток бронирования

Client → API Gateway → Booking Service → Supplier API → Database → Client

Критически важная транзакция с проверками доступности и фиксацией резерва у поставщика.

Масштабирование и производительность

Горизонтальное масштабирование:

• Business services: добавление подов в K8s
• Database: read-реплики, партиционирование
• Cache: Redis Cluster
• Message queue: добавление брокеров Kafka

Производительность:

• Cache hit rate: 85-95% (цель)
• API response time: <200ms (P95)
• Database queries: <50ms (P95)

Безопасность и надёжность

• API ключи с rate limiting для Partner API
• Мониторинг через Prometheus с алертингом
• Backups PostgreSQL + Redis snapshots
• Health checks для всех сервисов
• Circuit breakers для внешних API

Этапы развёртывания

1. Разработка — все сервисы на одном сервере (30€/мес)
2. Запуск — разделение app/db серверов (90€/мес)
3. Масштабирование — Kubernetes кластер (от 200€/мес)

Связанная документация

Документ	Описание
Слои архитектуры	Детальное описание каждого из 6 слоёв
Схема базы данных	Структура PostgreSQL: таблицы, индексы, связи
Бизнес-сервисы	Search, Pricing, Booking, Tour Builder
API контракты	REST endpoints, схемы запросов и ответов
Хранилище данных	PostgreSQL + Redis: конфигурация и TTL
Слой приёма данных	Parsers, Matcher, Message Queue
Поставщики	Stuba, HomeToGo и другие адаптеры
Клиенты	Website, Partner API интеграции
Развёртывание	Этапы: dev → launch → scale
Дорожная карта	Этапы разработки и приоритеты