Перейти к основному содержимому

Техническое задание для подрядчика на разработку платформы Vitiana

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

Версия 2.0 обновлена под каноничную архитектуру Фаз 4–10 (опубликованы 25–27.04.2026): payment domain, security architecture, compliance & legal, 14 каноничных booking states, multi-tenant isolation strength, Tour Builder operational model, runbooks (8 incident classes), SLA model (10 SLI, 4 tier, on-call 5 уровней), DR & capacity (4 recovery tiers), data platform (6 классов событий), ML platform, A/B testing, analytics, notifications, media, i18n, economic model. Также интегрированы 3 open proposals для стадии 1: stack roadmap, stack detailed discussion (RU), OpenAPI-first polyglot codegen. Добавлены ссылки на 5 каноничных архитектурных правил-законов (с правилом 00000 как высшим приоритетом).

Назначение документа​

Этот документ — техническое задание для подрядных организаций, оценивающих разработку платформы vitiana-api-platform. Документ предназначен для:

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

Документ описывает: предметную область, область применения, целевую архитектуру, функциональные и нефункциональные требования, технологический baseline, фазовую модель реализации, требования к команде, критерии приёмки, формат сотрудничества, открытые развилки.

Документ не содержит финансовой оценки. Стоимость разработки — обязанность подрядчика. Заказчик ожидает обоснованную оценку с разбивкой по фазам, компонентам, ролям. Заказчик не предоставляет ориентировочный бюджет; подрядчик формирует его на основе требований этого ТЗ.

Документ читается совместно с главной архитектурной осью и связанными документами vitiana-api-platform, перечисленными в разделе 21.

Для предварительной оценки до подписания NDA существует абстрагированная выжимка: Краткое техническое задание (резюме для внешней оценки) — без названий организации, продуктов, поставщиков, конкретных инструментов, цепочек документов, сроков и бюджетов. Передаёт суть, цели, шесть архитектурных осей, семь принципов разработки, целевые качественные характеристики и фазированный подход. Используется для первичного контакта с потенциальными подрядчиками, общей оценки масштаба, экспертных консультаций без передачи внутренней информации.

1. Краткое описание проекта​

1.1. Что разрабатывается​

Платформа vitiana-api-platform (далее — Платформа) — глобальная гибкая модульная B2B-платформа верхнего уровня для туристической индустрии. Платформа объединяет данные туристических услуг от множества поставщиков и продаёт доступ к этим данным разным каналам продаж: туристическим агентствам, корпоративным службам путешествий, белым-лейбл-партнёрам, собственным B2C-витринам.

Главные продуктовые компоненты:

  • B2B API marketplace — основной коммерческий продукт; платный программный интерфейс (API) для интеграции партнёров;
  • Tour Builder — модульный конструктор сложных туров через закрытый API;
  • Vitrip.store — собственная B2C-витрина платформы (демонстрация и собственный канал продаж);
  • Agency working surface — рабочее место для туристических агентств.

1.2. Целевое состояние​

Зрелая платформа верхнего уровня, реализующая 6 архитектурных осей (каноничная доменная, поверхности взаимодействия, платформа как продукт, ось данных и интеллекта, операционная, связь с реализацией) с production-ready возможностями:

  • Каноничная доменная модель — 7 групп сущностей (canonical master / supplier-derived / operational offer / transactional / composition / governance / identity-tenancy) с явными жизненными циклами;
  • Каноничная статусная машина бронирования — 14 канонических состояний с обработкой unknown_external_state (target SLI менее 1%);
  • Tour Builder operational model — composition rules engine, transaction saga с компенсациями, drift detection;
  • Платёжный домен — PaymentIntent lifecycle, multi-PSP integration, refund/chargeback workflows, PCI DSS через PSP-only handling (SAQ A);
  • Программный интерфейс как продукт — 4 tier model (Free / Starter / Professional / Enterprise) с SLA 95–99.9%, partner certification, deprecation policy;
  • Multi-tenant Enterprise-grade изоляция — 3 уровня (logical / dedicated_compute / dedicated_infrastructure), continuous IsolationBoundaryCheck;
  • Платформа данных и трекинг событий — 6 классов событий (domain / analytical / saga / audit / operational / compliance) с разными guarantees;
  • Machine learning платформа — feature store, model registry, model serving, model monitoring; use cases: ranking, recommendation, dynamic pricing, anomaly detection, supplier health prediction;
  • A/B testing framework — feature flags, cohort assignment, exposure tracking, guardrail metrics;
  • Notification platform — multichannel delivery (email/SMS/push/in-app/webhook) с consent management;
  • Media & content — MediaAsset, ContentBundle, on-the-fly transforms;
  • i18n — multi-currency (UAH/EUR/CZK/PLN/KZT/USD), multi-language (UK/RU/CZ/PL/EN/KZ);
  • Аналитика и BI — partner-facing dashboards с k-anonymization;
  • Архитектура безопасности — STRIDE threat model, IAM (RBAC + ABAC), encryption at-rest + in-transit, automated secret rotation 90 дней, supply chain security;
  • Соответствие требованиям регуляторов — GDPR + ePrivacy + UA/CZ/PL local + KZ + PSD2 + EU TOMS + Package Travel Directive + AML/KYC; SOC 2 Type 1 (Phase 4), Type 2 (Phase 5), ISO 27001 (Phase 6);
  • Operational maturity — 8 каноничных incident classes с runbooks, 5-уровневая on-call structure, 4 recovery tiers с DR drills, capacity planning по фазам;
  • Динамическая тарификация платформенных услуг (формула: search calls × сложность + quote / booking / ML inference / supplier load + storage + bandwidth);
  • Multi-region инфраструктура на четвёртой фазе с явными RTO/RPO targets per tier.

1.3. Текущее состояние​

Существует первая итерация ingestion-слоя в виде кода-проекта home-to-go-api:

  • работающий поставщик Stuba (production-ready 2026-04-15);
  • 127 304 отелей загружено, 4.6 миллиона фотографий;
  • 182 страны синхронизированы;
  • база apivitianadb PostgreSQL 18.1 с задеплоенными схемами hotels, usr, events_themes, geo, amenity;
  • сайт vitrip.store на Preact + HTM, PHP backend.

Эта реализация — первая итерация, не соответствует целевой каноничной архитектуре по нескольким направлениям. См. overview/relation-to-implementation-baseline.md для полной карты соответствия и технического долга.

1.4. Подход к разработке​

Платформа разрабатывается по фазовой модели с метрическими и доменными триггерами перехода между фазами. Не календарный план, а движение по triggers (см. раздел 8).

Разработка ведётся параллельно с сохранением работы существующей реализации: новая каноничная модель строится на новой инфраструктуре; старая реализация постепенно депрекатируется через dual-write и controlled switchover.

Никаких MVP-заглушек, captive-интеграций под одного поставщика, временных решений без плана миграции. Каждое решение проектируется как зрелое (см. раздел 4 о принципах).

2. Архитектурный baseline​

Полная архитектура зафиксирована в документах overview/. Подрядчик обязан изучить их перед формированием коммерческого предложения. Краткая карта:

2.1. Шесть архитектурных осей верхнего слоя​

ОсьДокументГлавный фокус
1overview/canonical-domain-spine.mdКаноничные сущности, контуры истины, жизненные циклы
2overview/layers.mdПоверхности взаимодействия (6 surfaces), контракты, видимость
3overview/platform-as-product.mdТарифные уровни, динамическая тарификация, developer experience, SLA
4overview/data-and-intelligence-spine.mdСобытия, DWH, ETL, ML, A/B-тестирование
5overview/operational-spine.mdЭластичность, фазы упаковки, надёжность, инциденты, релизы
6overview/relation-to-implementation-baseline.mdСвязь с home-to-go-api, технический долг, путь конвергенции

Граф пересечений всех осей — overview/architectural-axes-and-cross-links.md.

2.2. Документы второго круга (reference/)​

Раскрывают доменные модели детально. Группированы по архитектурной роли.

2.2.1. Каноничная доменная модель​

2.2.2. Коммерческая и финансовая модели​

2.2.3. Платформа как продукт​

2.2.4. Платформенные домены — surfaces, search, content, communication​

2.2.5. Платформа данных и интеллекта​

2.2.6. Безопасность, соответствие, бизнес-логика​

  • reference/security-architecture.md — архитектура безопасности: STRIDE threat model, IAM (RBAC + ABAC), encryption, secret lifecycle, supply chain security, audit log immutable;
  • reference/compliance-and-legal.md — соответствие требованиям регуляторов: GDPR / PSD2 / EU TOMS / Package Travel Directive / KZ data law / AML/KYC; SOC 2 / ISO 27001 timelines;
  • reference/business-services.md — сервисная декомпозиция (30+ контуров).

2.2.7. Хранение и технологии​

2.3. Документы операционного слоя (operations/)​

2.3.1. Операционная зрелость (Фаза 6)​

2.3.2. Развёртывание, наблюдаемость, релизы​

2.4. Документы развития (development/)​

2.4.1. Дорожные карты и planning​

2.4.2. Governance документации​

  • development/documentation-governance.md — каноничный процесс работы с документами: 8 принципов (включая no destruction, single source of truth, MDX-safe writing), 5-фазный жизненный цикл, роли и ответственности, метрики качества.

2.4.3. Архитектурные правила-законы​

Высший приоритет в архитектурных решениях:

2.4.4. Async и sync контракты (фундамент Фазы 3, расширены под Фазы 4–6)​

2.4.5. Открытые предложения (proposals)​

Не утверждённые архитектурные решения, требующие финализации на стадии 1 implementation baseline:

2.4.6. Исторические review-документы​

Совокупно — более 90 документов. Подрядчик обязан изучить все каноничные доменные документы (раздел 2.2.1) и операционной зрелости (раздел 2.3.1) полностью перед формированием предложения; остальные — с разной глубиной по relevance к компоненту работ.

3. Область работ (scope of work)​

Полный scope — реализация целевой платформы по архитектуре. Разделяется на компоненты по архитектурным осям и поверхностям взаимодействия.

3.1. Каноничный доменный слой​

Включает:

  • проектирование и реализация каноничной схемы хранения с разделением мастер-сущностей, supplier-derived сущностей, операционных сущностей, транзакционных сущностей, композиционных сущностей, governance-сущностей, identity/tenancy сущностей;
  • миграционные сценарии с существующей apivitianadb (схема hotels, usr, events_themes и других) на каноничную схему;
  • реализация бизнес-логики жизненных циклов сущностей (Property lifecycle, Offer lifecycle, Quote lifecycle, Booking state machine, TourDraft/Proposal lifecycle, Review lifecycle);
  • реализация политик истины, свежести, повторной проверки (truth/freshness/revalidation policies);
  • реализация полей происхождения данных (FieldLineage) и маппингов поставщиков с явными решениями (MappingDecision, MergeDecision, SourcePrecedenceRule).

Главные входные документы:

3.2. Слой приёма данных от поставщиков (ingestion)​

Включает:

  • адаптеры приёма данных от поставщиков (минимум — Stuba, HomeToGo на старте; архитектура для подключения 5+ поставщиков на фазе 2 и десятков на фазе 3+);
  • абстрактный слой нормализации, переводящий любые supplier-форматы в каноничную модель;
  • персистентный supplier trace layer (raw payloads, sync runs, parse failures);
  • движок маппинга и матчинга с возможностью ручного review;
  • движок обнаружения аномалий и автоматического карантина;
  • replay capability как first-class возможность;
  • сигналы downstream (cache invalidation, repricing triggers, publication gating events).

Главные входные документы:

3.3. Operational offer/quote/commercial слой​

Включает:

  • Offer Service: формирование offers из каноничной модели, freshness logic, revalidation logic;
  • AvailabilitySnapshot и PriceSnapshot;
  • Quote Service: actor-aware commercial fixation, validity windows, applied commercial policy trace, repricing logic;
  • Commercial rule engine: пять смысловых уровней цены (supplier raw → normalized base → commercial rule output → quoted → settlement-relevant);
  • channel-aware visibility per surface;
  • блокирующая публикация при недостаточной целостности (Offer Integrity gating);
  • search projection: поисковая проекция с consistency между каноничной истиной и поисковым индексом.

Главные входные документы:

3.4. Транзакционный слой бронирования (booking)​

Включает:

  • Booking Service с 14 каноничными состояниями жизненного цикла (см. reference/booking-state-machine.md): draft → submitted → pending_revalidation → pending_supplier_confirmation → supplier_confirmed → platform_confirmed → partially_confirmed → unknown_external_state → failed → cancel_requested → cancel_in_progress_supplier → cancelled → amendment_in_progress → completed;
  • идемпотентность всех критических операций (create, confirm, cancel, amend) с поддержкой client-supplied idempotency keys;
  • audit trail для всех transitions;
  • обработка unknown_external_state (8-е каноничное состояние) с recovery procedures; target SLI менее 1% (см. operations/sla-and-on-call-model.md);
  • разделение supplier_confirmed (positive ack от поставщика) и platform_confirmed (financial/transactional commit на платформе) — НЕ один атомарный момент;
  • compensating transactions при неуспехе через saga pattern;
  • post-booking lifecycle (отмены, изменения, supplier-driven disruption, support cases, refund/compensation decisions, communication records).

Главные входные документы:

3.5. Композиционный слой (Tour Builder)​

Включает:

  • модульный raw API constructor с компонентами:
    • модуль размещения (accommodation segment);
    • модуль переезда (transfer segment) — авто, авиа, ж/д, водный;
    • модуль активности (activity, experience);
    • модуль услуги (service: гид, виза, страховка);
    • модуль аренды транспорта (transport rental);
    • модуль страхования (insurance);
    • пользовательский модуль (custom block);
    • информационный модуль (informational block);
  • stateful workflow: TourDraft → DraftItem → DraftVariant → TourProposal → ProposalVersion → ProposalArtifact;
  • проверка совместимости компонентов (time continuity, geo continuity, capacity matching, occupancy compatibility, policy compatibility, commercial coherence);
  • per-tour pricing с учётом per-tour markup, package discount, all-inclusive bundling;
  • drift handling: отслеживание изменений в underlying offers и их эффект на собранный тур;
  • per-tour merchant-of-record decision tree;
  • генерация артефактов (PDF, share-links, branded exports).

Главные входные документы:

  • reference/tour-builder-domain.md — доменная модель композиции (TourDraft / TourProposal / DraftVariant / ProposalArtifact);
  • reference/tour-builder-operational-model.md — операционная модель: CompositionRule engine, TourBookingTransaction saga с компенсациями, DriftEvent, CompensationEvent, state machines TourDraft и TourProposal.

Партнёрский Tour Builder UI/SDK (правило 00000): партнёры с тарифом Professional+ получают полноценный peer Tour Builder UI/SDK (npm package @vitiana/tour-builder через Vite library mode), не упрощённую копию agency Tour Builder. См. reference/clients.md — Surface 4 (Partner UI/SDK).

3.6. Финансовый и взаиморасчётный слой​

Включает:

  • Partner Finance & Clearing: партнёрские лицевые счета (Partner Financial Account), клиринговые балансы (Clearing Balance), депозиты, кредитные лимиты, удержания, клиринговые записи (Clearing Entry), правила взаимозачёта (Netting Rule);
  • Settlement Service: пять уровней финансовой реальности (quoted promise → booking-time commercial basis → supplier settlement basis → platform internal financial basis → reconciled financial reality);
  • Settlement event generation;
  • Reconciliation queues (несколько уровней: quote-to-booking, booking-to-supplier, internal settlement, refund/amendment, lifecycle);
  • Discrepancy classes и их обработка;
  • Refund, cancellation, amendment economics с детальными правилами по компонентам;
  • Currency и rounding policies с явными правилами для каждой операции.

Главные входные документы:

3.7. Слой тенантов, идентичности, доступа​

Включает:

  • Tenant + Workspace модель с явной 3-уровневой isolation strength (logical / dedicated_compute / dedicated_infrastructure) — выбирается per tenant tier (см. reference/multi-tenant-isolation-strength.md);
  • IsolationBoundaryCheck — continuous automated check с target 0 cross-tenant breaches за rolling 90 дней;
  • User, ActorContext, Identity модель — User и ActorContext мыслятся раздельно (один user в разных контекстах);
  • Role, Capability, Scope с тонкой гранулярностью; каноничный resolver GET /capability/me (см. reference/clients.md);
  • ApiClient и ApiCredential management с жизненным циклом (создание, scope assignment, environment binding, automated rotation 90 дней, отзыв);
  • Tenant Configuration Service: пер-тенант policy для поставщиков, коммерческих условий, финансовой модели, surface-доступности, тарифа, isolation level, DR class;
  • Tenant Enablement lifecycle (pre-onboarding, configuration, credentials, supplier enablement, financial enablement, controlled activation, certification).

Главные входные документы:

3.8. API as Product​

Включает:

  • Partner API Surface как продукт (не просто внешний API): полная изоляция, версионирование с явной политикой совместимости, deprecation policy, окно совместимости, sandbox с реалистичными mock-данными, self-service onboarding, certification flow с интеграционными тестами, KYC/AML на партнёра;
  • Developer Portal: документация (OpenAPI specs, AsyncAPI specs, changelog, migration guides), code samples и SDKs (минимум Python, Go, JavaScript/TypeScript), Postman/HTTP collections, interactive API explorer, searchable knowledge base;
  • Partner Console (self-service): account dashboard, API key management, webhook subscription management, usage dashboard, quota alerts, audit log download, support ticket system, tier upgrade/downgrade, compliance documents access;
  • Tariff & Billing Engine: 4 тарифных уровня (Free, Starter, Professional, Enterprise) с явными envelope; динамическая тарификация по нагрузке, supplier load profile, query complexity, ML inference, Tour Builder operations, webhook deliveries, storage usage; bulk-discount; overage rates; self-service tier changes.

Главные входные документы:

3.9. Слой данных и интеллекта​

Включает:

  • Events Tracking platform: schema-aware events, разделение domain events vs analytical events, governance схем, privacy-bounded захват;
  • Event Bus: managed Kafka (или эквивалент), domain event delivery, replay capability, dead-letter handling, multi-region (на фазе 4);
  • Webhook Delivery: к партнёрам, signature verification, retry policy, redelivery, версионирование payload schema;
  • Data Warehouse: managed ClickHouse (или эквивалент) на фазе 3+, append-only event log, materialized views, snapshots каноничных сущностей, ML feature store, experiment data;
  • ETL/streaming pipelines: real-time (Kafka Streams, Flink или эквивалент), batch (Spark, Apache Beam или эквивалент), CDC из транзакционного слоя;
  • ML Platform: feature store (Tecton, Feast или собственная реализация), model registry (MLflow), model serving (TorchServe, Triton, BentoML или эквивалент), model monitoring;
  • ML use cases (по фазам): search ranking, recommendation, dynamic pricing, anomaly detection в ingestion, partner risk scoring, conversion optimization, fraud detection, content moderation, demand forecasting, Tour Builder compatibility scoring, supplier health prediction;
  • A/B Testing Framework: feature flags, cohort assignment, exposure tracking, metrics framework (primary/secondary/guardrail), statistical significance, experiment lifecycle;
  • Analytics & BI: внутренняя аналитика для команды, partner-facing analytics product как часть Professional/Enterprise тарифов (usage analytics, performance analytics, conversion analytics, supplier breakdown, commercial analytics, cohort analytics, comparative benchmarks).

Главные входные документы:

3.10. Платёжный слой​

Включает:

  • Payment Domain Service с каноничными сущностями: PaymentIntent, PaymentTransaction, Refund, Chargeback, Settlement, PayoutBatch, PaymentMethod (только PSP-токены, никогда PAN);
  • PaymentIntent lifecycle координирован с booking state machine: created → awaiting_method → method_attached → authorized → captured → succeeded или canceled / failed;
  • Multi-PSP integration через единый адаптер (Stripe / Adyen / Mollie или другой; конкретный выбор — открытая развилка стадии 1, см. proposal-openapi-first-polyglot-codegen);
  • 3DS 2.0 / SCA для PSD2 EU compliance — handled by PSP, не self-hosted;
  • PCI DSS через PSP-only handling (SAQ A) — card data никогда не касается серверов Vitiana, только PSP-токены;
  • Refund mechanics (полный, частичный, своевременность);
  • Chargeback workflow с dispute response automation;
  • Idempotency keys обязательны для всех mutating operations;
  • Saga для multi-component tour bookings — координирует payment lifecycle с booking lifecycle;
  • Merchant-of-record логика: гибридная per-tenant (Платформа MoR / Партнёр MoR / гибрид по продуктам);
  • payment methods coverage по странам первой волны (UA, CZ, PL, KZ);
  • Payment data — Tier 1 storage (RTO 60м, RPO 5м), 7 лет retention (financial records);
  • Tenant-aware PSP routing для регулируемых юрисдикций (например, EU tenant → Stripe EU, KZ tenant → local PSP);
  • SLI 7 (payment success rate) — target менее 1% rejected при штатной нагрузке.

Главные входные документы:

3.11. Слой соответствия требованиям регуляторов​

Включает:

  • GDPR-compliance infrastructure:
    • DSR (Data Subject Request) workflow для всех категорий данных через каноничный API: GET /privacy/data-export, POST /privacy/data-correct, POST /privacy/data-delete, POST /privacy/processing-restrict, POST /privacy/processing-object;
    • DPA (Data Processing Agreement) с партнёрами как обязательный шаг certification flow;
    • sub-processor lists публично доступны;
    • cross-border transfer mechanisms (SCCs UA↔EU, KZ↔EU);
    • data minimization в захвате данных через data_field_inventory с lawful basis per поле;
    • retention с автоматическим удалением (Tier 1: 7 лет / Tier 3: 90 дней / Tier 4: archived);
    • audit trail доступа к PII в immutable WORM storage (см. security-architecture);
    • SLA на ответ DSR: 30 дней (legal max), цель 7 дней;
  • EU Package Travel Directive: insolvency protection (financial guarantee через bond/insurance/trust account), pre-contractual information requirements, liability for performance — реализация per merchant-of-record модель;
  • EU TOMS: маржинальный режим VAT для tour operators (margin = revenue − supplier cost), quarterly VAT returns;
  • PSD2 / SCA: strong customer authentication при платежах в EU — handled by PSP (см. payment-domain.md);
  • PCI DSS — через PSP-only handling (SAQ A);
  • Cookie Directive (ePrivacy): explicit opt-in consent для analytics/marketing cookies, granular consent management, easy withdrawal;
  • Local privacy laws:
    • UA — Закон Украины «Про захист персональних даних» (близок к GDPR);
    • CZ — Zákon o ochraně osobních údajů 110/2019 (GDPR-aligned);
    • PL — Ustawa o ochronie danych osobowych с дополнительными требованиями для marketing consent;
    • KZ — Закон РК «О персональных данных» с требованием data localization (data KZ residents должны храниться в KZ region) → требует dedicated_infrastructure для KZ tenants;
  • AML/KYC на партнёров: процедура проверки при certification flow (Customer Due Diligence + Enhanced для high-risk + Sanctions screening); фаза 4+ при росте volumes;
  • DAC7 / DSA: reporting обязательства online platforms;
  • UA tax regime, KZ tax regime: отдельные налоговые режимы с собственным учётом;
  • Privacy by Design: каждый новый feature/domain проходит privacy review до production deployment;
  • Breach notification: 72 часа на уведомление supervisory authority, без неоправданной задержки уведомление affected Data Subjects;
  • DPO (Data Protection Officer): mandatory при регулярном крупномасштабном monitoring (фаза 6 при достижении threshold);
  • Compliance maturity по фазам: GDPR baseline (Phase 1) → PSD2 / PCI DSS (Phase 2) → EU TOMS / Package Travel (Phase 3) → AML/KYC + SOC 2 Type 1 (Phase 4) → SOC 2 Type 2 (Phase 5) → ISO 27001 + DPO (Phase 6);
  • Audit log как Tier 1 immutable WORM storage для compliance trace, 7+ лет retention;
  • Data residency controls для tenant-specific географических требований через dedicated_infrastructure;
  • Encryption at-rest + in-transit + per-tenant keys для Enterprise (CMK).

Главные входные документы:

3.12. Слой коммуникации и уведомлений​

Включает:

  • Каноничные сущности: NotificationTemplate, NotificationEvent, NotificationChannelDelivery, ConsentLog, WebhookSubscription, WebhookDeliveryAttempt;
  • Multichannel delivery:
    • Customer-facing email: confirmation, vouchers, disruption notifications, refund notifications, marketing (с opt-in/opt-out);
    • Customer-facing SMS: time-critical уведомления (booking confirmation, disruption);
    • Push notifications: mobile (фаза позже);
    • In-app notifications: для рабочих кабинетов агентств и партнёрских dashboards;
    • Partner webhooks: domain event delivery с HMAC signature verification, retry policy с exponential backoff, DLQ для unreachable endpoints, redelivery semantics, версионирование payload schema, ordering assumptions;
    • Internal alerts: для on-call team, governance team, finance team;
  • Multilingual templates через каноничный i18n (см. internationalization-and-localization);
  • Consent log как GDPR-grade immutable record;
  • Webhook delivery SLI (см. sla-and-on-call-model.md): tier-зависимая latency p95 (5–30 секунд);
  • Communication audit trail: какие коммуникации были отправлены кому и когда — Tier 1 retention (7 лет);
  • GDPR consent verification обязательна для marketing channels — без opt-in marketing email не fire'ится;
  • Email/SMS providers через единый абстрактный layer: SendGrid / Mailgun / Postmark / Amazon SES / Twilio / Vonage / locale-specific.

Главные входные документы:

3.13. Слой медиа и контента​

Включает:

  • Каноничные сущности: MediaAsset, ContentBundle, ContentTranslation, MediaTransformCacheEntry;
  • Image normalization pipeline: resize, format convert (WebP, AVIF), content moderation через ML для inappropriate content;
  • Image deduplication: один и тот же отель у разных поставщиков может иметь одинаковые фото;
  • Image attribution и copyright tracking через MediaAsset metadata;
  • CDN strategy: для собственного канала и потенциально для партнёров (через Object Storage signed URLs);
  • On-the-fly image transforms (responsive images через transform query params): Cloudflare Images / imgix / Cloudinary / собственное на основе imagemagick / sharp;
  • Object Storage: S3-совместимое хранилище для images, PDF (proposal artifacts), generated exports, archived supplier artifacts;
  • File storage: для tenant-specific атачментов в operational workflows;
  • Tour Builder integration: TourProposal reference на MediaAsset, ProposalArtifact (PDF, share-link) — generated assets, drift detection при изменениях supplier media;
  • DR mapping: MediaAsset metadata — Tier 2 (RTO 4ч); raw media — Object Storage cross-AZ; transform cache — Tier 3 (rebuildable); archived media (старше 2 лет без access) — Tier 4 cold storage;
  • GDPR erasure: user-uploaded media обязательно удаляется при DSR delete; supplier media (общественная) — не удаляется (no PII).

Главные входные документы:

3.14. Слой интернационализации и локализации​

Включает:

  • Каноничные сущности: SupportedLanguage, SupportedCurrency, FxRateSnapshot, TranslationString (UI strings);
  • Translation workflow: machine translation для базовых описаний, human review для важных компонентов, hybrid pipeline;
  • Multi-language data layer: source language → canonical language policy → requested presentation language → fallback chain;
  • Multi-currency: cross-currency rates через FxRateSnapshot с reference timestamps, conversion source, rounding rules per currency;
  • Timezone handling: для booking dates (TZ отеля vs TZ клиента), для display, для events;
  • Locale formatting: numbers, dates, currencies, names per locale;
  • Pluralization rules per language;
  • Языковая поддержка минимум: украинский (UK), русский (RU), чешский (CZ), польский (PL), английский (EN), казахский (KZ);
  • Валютная поддержка минимум: UAH, EUR, CZK, PLN, KZT, USD;
  • Regulatory text translations (legal disclosures, T&Cs per jurisdiction) — отдельный класс с phasing review (см. compliance-and-legal.md);
  • i18n consumed by all surfaces — клиенты потребляют единый сервис, не реализуют свой FX converter.

Главные входные документы:

3.15. Поверхности взаимодействия​

Включает:

Internal Operational Surface​

Внутренние инструменты для команды Vitiana:

  • governance review workspaces (mapping, merge, anomaly resolution);
  • supplier monitoring consoles;
  • booking exception handling;
  • reconciliation и finance support tools;
  • partner management console;
  • manual revalidation и override workflows;
  • audit trail viewers с полным lineage.

Agency Working Surface​

Полноценный рабочий кабинет для туристических агентств:

  • поиск туристических продуктов;
  • сравнение вариантов с явной видимостью applied commercial policy;
  • workflow создания quote с валидностью и причинами repricing;
  • booking workflow с явным state-tracking;
  • Tour Builder для составных продуктов;
  • generation и share клиентских proposals;
  • ведение customer context и истории взаимодействий;
  • agency-scoped reporting (продажи, комиссия, клиенты);
  • workspace-as-a-unit логика (рабочей единицей является tenant context, не только пользователь).

Partner API Surface​

Партнёрский внешний API как продукт:

  • REST + Webhooks (OpenAPI / AsyncAPI specs);
  • версионирование с deprecation policy;
  • environment separation (sandbox / production);
  • auth через scoped API keys;
  • contract-safe представление коммерческих сумм (без раскрытия маржинальной структуры);
  • partner-facing analytics access на Professional+ тарифах;
  • tier-aware compatibility windows.

B2C Storefront Surface (vitrip.store)​

Собственная B2C-витрина:

  • read-heavy traffic с высоким cache hit ratio;
  • conversion-оптимизированный UX;
  • multi-language, multi-currency representation;
  • legal compliance (GDPR cookie consent, PSD2 SCA, Package Travel Directive disclosure);
  • self-service booking history и cancellations;
  • proposal viewing по share-ссылкам от агентов;
  • интеграция с маркетинговыми инструментами.

Service-to-Service Surface​

Внутренние сервисные контракты:

  • gRPC + Kafka events;
  • mTLS + service identities (zero-trust networking);
  • idempotency + replay safety;
  • schema discipline для всех событий и команд;
  • strong observability с distributed tracing.

Tour Builder Closed Surface​

Закрытый API для собственных интерфейсов и платящих партнёров:

  • модульные composition primitives (см. 3.5);
  • доступ через quasi-Partner API surface, но с отдельной коммерческой моделью (paid Tour Builder tier);
  • Webhooks для async выполнения тяжёлых композиционных операций.

Главные входные документы:

3.16. Операционная инфраструктура​

Включает:

  • Эластичная инфраструктура с авто-масштабированием с нулевого дня;
  • Изоляция контуров исполнения (canonical/transactional, offer/quote, ingestion, surface delivery, governance, observability);
  • Capacity envelopes per tenant tier;
  • Backpressure discipline на async очередях;
  • Graceful degradation при перегрузке;
  • Базовая инфраструктура: VPS Bootstrap → Bare Metal Advance → Bare Metal Scale → multi-region (по фазам, см. operations/scaling-and-packaging-roadmap.md);
  • Managed services: PostgreSQL, Kafka, OpenSearch, ClickHouse, Object Storage, Kubernetes, Grafana — у OVHcloud (или эквивалентный провайдер);
  • Открытые стандарты везде, без vendor lock-in.

Observability​

  • Metrics (operational + domain);
  • Distributed tracing (через correlation IDs);
  • Structured logging;
  • Dashboards (operational + tenant-facing на Professional+ тарифах + executive);
  • Alerting с severity levels (Critical / High / Medium / Low) и явными triggers;
  • Anomaly detection (на фазе 3 через ML).

Disaster Recovery​

  • 4 каноничных recovery tiers с RTO/RPO (см. operations/disaster-recovery-and-capacity.md):
    • Tier 1 (Payment, Booking, Audit log, User/Tenant): RTO 60м, RPO 5м, 7 лет retention;
    • Tier 2 (Offer, Quote, Search projection, Notifications): RTO 4ч, RPO 30м;
    • Tier 3 (Analytics, ML feature store, Logs): RTO 24ч, RPO 1ч;
    • Tier 4 (Archived): RTO 7д.
  • 5 типов DR drills (backup_verify ежедневно / partial_restore ежемесячно / full_restore ежеквартально / region_failover каждые 6 месяцев / chaos_drill ежемесячно phase 4+);
  • 5-шаговая процедура восстановления: declared → point selected → restored to staging → smoke tests → promoted to production;
  • Geo-redundant backup на фазе 4 (multi-region active-active);
  • Capacity planning с peak load forecasting и auto-scaling integration.

Release Engineering​

  • Feature flags (LaunchDarkly, Unleash или собственная реализация);
  • Tier-зависимый canary: Enterprise — first canary (counter-intuitive, но stripe/twilio practice — Enterprise integrated глубже, регрессии раньше детектируются), затем Professional, Starter, Free;
  • Automatic rollback triggers при degradation SLI metrics в canary;
  • Error budget gate — release требует additional approval, если tenant tier уже использовал >50% месячного error budget;
  • Contract testing (Pact paradigm) для предотвращения breaking changes;
  • Schema migrations через migration tools (Flyway, Liquibase, или эквивалент);
  • Compatibility windows для Partner API: Free/Starter — 6 месяцев, Professional — 12 месяцев, Enterprise — custom (по контракту);
  • Booking state migrations: forward-compatible only, no state collapse без major version bump;
  • Saga migrations: backward-compatible compensation для running sagas;
  • Supply chain security: SBOM generation per release, vulnerability scanning, code signing (Cosign), trusted base images (см. reference/security-architecture.md).

Incident Management​

  • 8 каноничных incident classes с runbooks (см. operations/runbooks-incident-playbooks.md):
    1. Supplier degradation;
    2. Stale offer state;
    3. Quote repricing surge;
    4. Booking timeout / unknown_external_state;
    5. Cache invalidation failure;
    6. Governance queue overload;
    7. Delayed settlement event generation;
    8. Broken publication pipeline;
  • Severity levels (Critical / High / Medium / Low) с явными response times и tenant communication protocols;
  • 5-уровневая on-call structure (Primary → Secondary → Engineering Manager → Director/VP → CTO/CISO) — см. operations/sla-and-on-call-model.md;
  • 24/7 on-call rotation для Critical/High инцидентов с фазы 3+;
  • Burnout protection: не более 1 недели on-call per engineer per 4–8 weeks (фазо-зависимо);
  • Incident commander role один человек на каждом инциденте Critical/High;
  • Blameless post-mortems с action items, обязательны для major incidents;
  • Status page (публичная) — Statuspage.io / Atlassian Statuspage / собственная;
  • Tenant communication протоколы через notifications: webhooks для tenants о критических инцидентах + email для Enterprise + post-incident report.

SLA Model​

  • 4 SLA tier (Free best-effort / Starter 95% / Professional 99% / Enterprise 99.9%);
  • 10 каноничных SLI metrics: availability per surface, latency p95, webhook delivery, search freshness, booking confirmation latency, unknown_external_state ratio (target менее 1%), payment success rate, restoration success, MTTR, support response time;
  • Service credits при breach: 5% / 10% / 25% / 50% от месячной подписки tenant с автоматической выплатой через self-service;
  • Error budget per tier с burn rate alerting.

Главные входные документы:

4. Принципы разработки​

Подрядчик обязан соблюдать следующие принципы. Нарушение любого — основание для отказа от приёмки.

Каноничные 5 архитектурных правил-законов опубликованы как отдельные документы в development/ и имеют высший приоритет в архитектурных решениях:

  1. Закон 00000 — платформа главенствует над поставщиками — высший приоритет над всеми остальными;
  2. Современные лучшие практики верхнеуровневых платформ;
  3. Эластичное масштабирование и упаковка по фазам;
  4. Развитие без деградации;
  5. Тезисное обоснование архитектурных решений.

Дополнительно (документная дисциплина):

При конфликте между разделом 4 этого ТЗ и каноничным документом-законом — закон выигрывает.

4.1. Правило 00000 — платформа над поставщиками​

Каноничная модель Vitiana проектируется от целей платформы, не от структур поставщиков. Любой поставщик отключаем без переделки ядра. Поле в каноничной модели появляется потому, что домен Vitiana требует его, а не «у Stuba так». Каноничный источник: Закон 00000.

4.2. Современные лучшие практики​

Архитектура опирается на паттерны платформ верхнего уровня (Stripe, Twilio, Algolia, Cloudflare, Snowflake, Vercel, Plaid). Не legacy-подходы туристической индустрии. Чужие практики переосмысливаются и улучшаются, не копируются.

Запрещены:

  • monolithic database с shared state между всеми доменами;
  • synchronous chains через >2 сервиса в критическом пути;
  • god services;
  • CRUD-style API над domain entities;
  • distributed monolith;
  • manual reconciliation как штатный путь;
  • captive integration с одним поставщиком, PSP, cloud provider.

4.3. Развитие, не деградация​

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

Допустимо: incremental delivery зрелой архитектуры по фазам, если каждая фаза не создаёт долг, который позже потребует переписывания.

Запрещено:

  • «сейчас одна модель, потом разделим»;
  • «сейчас один surface, потом добавим нюансы»;
  • «сейчас один storage, потом разнесём»;
  • «сейчас события одной формы, потом усилим».

4.4. Открытые стандарты, без vendor lock-in​

Все технологические выборы — по открытым стандартам:

  • PostgreSQL (стандарт), не Aurora/Spanner;
  • S3-совместимое объектное хранилище, не проприетарный формат;
  • Kafka, не Kinesis;
  • Kubernetes API, не EKS-специфичные расширения;
  • Redis-совместимый Valkey, не проприетарный;
  • OpenAPI / AsyncAPI / gRPC — стандартные контрактные форматы.

4.5. Тезисное обоснование решений​

Каждое нетривиальное архитектурное решение в коде и документации содержит:

  • цель решения;
  • 3-5 тезисов поддержки;
  • 1-2 отклонённые альтернативы с обоснованием;
  • принимаемые компромиссы (trade-off);
  • связь с другими решениями.

Запрещены формулировки «так лучше», «все так делают», «это очевидно» без раскрытия.

4.6. Разработка через Domain-Driven Design​

  • Bounded contexts с явными границами;
  • Ubiquitous language внутри каждого контекста;
  • Aggregates как unit of consistency;
  • Domain events как способ коммуникации между bounded contexts;
  • Hexagonal architecture (ports & adapters) для изоляции domain core от external dependencies (поставщиков, PSP, surface contracts).

4.7. Идемпотентность, replay safety, observability​

  • Все critical mutation-операции идемпотентны (с client-supplied idempotency keys);
  • Все async consumers идемпотентны и replay-safe;
  • Schema discipline для всех событий и команд;
  • Strong observability через distributed tracing с correlation IDs;
  • Каждое S2S-взаимодействие порождает trace и метрики.

5. Технологический baseline​

Подрядчик предлагает свой стек на основе требований. Заказчик имеет рекомендации в reference/implementation-technology-baseline.md и открытые proposals:

Ниже — каноничная рекомендация для finalization на стадии 1 implementation baseline с участием Tech Lead. Альтернативы рассматриваются при обоснованной аргументации подрядчика.

5.1. Языки программирования​

Phase 1 (Bootstrap, простой стек, два инструмента):

  • TypeScript primary для frontend и BFF-функций (B2C, agency, partner UI, internal operational surface, partner developer portal) — широчайший talent pool в EU/CIS;
  • Go primary для всего backend (booking, payment, partner API, notifications, ingestion, settlement, search service, governance) — built-in concurrency, low memory, no GC pauses, простой синтаксис.

Phase 3+ (по метрикам и triggered hiring):

  • Rust для critical paths по data-driven justification: pricing engine Tour Builder, search orchestrator (Elasticsearch wrapper), saga coordinator, payment innermost layer для extra security guarantees. НЕ с фазы 1 — Rust pool в EU/CIS узкий, hiring senior дорог; на bootstrap (4–8 человек) Rust преждевременен.

Phase 4+ (ML team formation):

  • Python только для ML inference + training (PyTorch / TensorFlow / scikit-learn / XGBoost / Hugging Face) и data science scripts. НЕ для production-сервисов вне ML — Python single-threaded GIL не подходит для high-volume backend.

5.2. Frontend frameworks​

Платформа имеет три разных продукта под одной архитектурой, каждому свой оптимальный инструмент (см. proposal-stack-roadmap-by-product-tier).

  • B2C сайт (vitrip.store) → Next.js 15 App Router (Node.js runtime):
    • Server Components + Server Actions для SEO (критично для travel — поисковая выдача Google = главный канал);
    • Deep linking через URL state (любая комбинация фильтров → отдельная server-rendered страница);
    • Streaming, partial hydration, edge rendering для Core Web Vitals;
    • Server Actions для безопасной работы с PSP (платёжные ключи никогда не попадают в браузер);
  • Admin / Agency / Tour Builder UI → Vite + React SPA (см. обоснование в proposal-stack-detailed-discussion-russian):
    • Tour Builder с drag-and-drop, real-time pricing, saga state visualization — natural fit для SPA, не SSR;
    • не нужен SEO (за паролем);
    • быстрый HMR (десятки минут экономии в день для активной разработки);
    • чистая SPA-модель — нет ментальной нагрузки server vs client components;
    • TanStack Router для типобезопасных маршрутов;
    • дизайн-система разделяется через npm package @vitiana/ui между Next.js и Vite приложениями;
    • Tour Builder packaged как npm library @vitiana/tour-builder (Vite library mode) — переиспользуется в agency app + partner app + B2C;
  • Partner UI portal → Next.js (отдельный subdomain или route group):
    • двойная природа — публичная маркетинговая часть требует SEO + dashboard для partner-операторов = Next.js поддерживает оба режима в одном приложении.

Что НЕ берём и почему:

  • ❌ Pure Node.js / Deno backend для всего — Tour Builder и search убьют performance первого Enterprise клиента;
  • ❌ Pure Go с server-rendered HTML templates — нет SEO benefit от Next.js, нет developer velocity, узкий пул фронтенд-разработчиков на Go;
  • ❌ SSR для админки и Tour Builder — drag-and-drop + real-time pricing = классическая SPA задача, SSR здесь лишняя сложность;
  • ❌ GraphQL без явной необходимости — на старте OpenAPI-first + REST + tRPC между Next.js и Go BFF проще; GraphQL имеет смысл с фазы 5+.

5.3. Persistent layer​

  • PostgreSQL 18+ как primary truth для canonical entities, transactional layer, governance, identity/tenancy. Текущий apivitianadb уже на этой версии.
  • Redis 7 (или Valkey) для volatile state, hot cache, rate windows, idempotency windows;
  • Search engine — фазированный путь:
    • Phase 1: PostgreSQL FTS (минимизация infrastructure, достаточно для 127K hotels);
    • Phase 2: Meilisearch (open-source, fast, simple, instant search) когда search becomes product feature;
    • Phase 4+: Elasticsearch / OpenSearch при необходимости (full power, но overkill для bootstrap);
  • Object Storage (S3-совместимое) для blobs (images, PDFs, supplier artifacts) — OVHcloud Object Storage;
  • DWH — фазированный путь:
    • Phase 2: DuckDB или ClickHouse single-node;
    • Phase 3: ClickHouse cluster;
    • Phase 5: managed (BigQuery / Snowflake) consideration по economics.

5.4. Async и messaging​

  • Phase 1: Redis Streams (durable, simple, suitable для бутстрапа);
  • Phase 3+: NATS Jetstream или Apache Kafka (managed Kafka — production-grade, complex ops, expensive);
  • Webhook delivery infrastructure с retry/redelivery/HMAC signature verification;
  • Schema registry для event schema evolution.

5.5. Container и runtime​

  • Docker для контейнеризации;
  • Managed Kubernetes (OVHcloud Managed Kubernetes Service, MKS) с фазы 1 — индустриальный стандарт, экосистема инструментов (Helm, Argo CD, Velero);
  • Pod Security Standards restricted profile в production;
  • Distroless / minimal base images, read-only root filesystem, non-root user, no privileged containers, dropped capabilities;
  • Service mesh (Istio или Linkerd) с фазы 3+ для mTLS service-to-service.

5.6. ML platform (Phase 4+)​

  • Feature store: Feast (open-source self-hosted) или Tecton (commercial) на фазе 4+;
  • Model registry: MLflow (open-source) — стандарт;
  • Model serving: TorchServe, Triton Inference Server, BentoML или эквивалент на фазе 4+;
  • GPU pools — dedicated через OVHcloud AI Endpoints или эквивалент.

5.7. Observability​

  • Prometheus + Grafana для metrics и dashboards с фазы 1;
  • Grafana Loki для structured logs с фазы 1;
  • Grafana Tempo / Jaeger для distributed tracing с фазы 2 (через OpenTelemetry collector);
  • Pyrra или Sloth для SLI/SLO calculation поверх Prometheus с фазы 2;
  • OpenTelemetry как стандарт инструментации;
  • SIEM (отдельный stack для security audit) — Wazuh / Datadog Security / Splunk с фазы 4+ (НЕ часть operational observability — security audit log имеет immutable WORM требования).

5.8. Secrets management​

  • Phase 0–1 (bootstrap): SOPS + Git (для simplicity);
  • Phase 2+: HashiCorp Vault (self-hosted) или managed (HCP Vault, OVHcloud Vault) с automated secret rotation 90 дней;
  • TLS certificates: cert-manager + Let's Encrypt automated rotation;
  • Internal mTLS CA с фазы 3+.

5.9. CI/CD и Infrastructure as Code​

  • Git-based source control (GitHub, GitLab или эквивалент) с pull request workflow;
  • CI/CD pipeline: GitHub Actions, GitLab CI или эквивалент;
  • Signed commits (GPG / SSH) обязательны для main / release branches;
  • SBOM generation (SPDX или CycloneDX) для каждого release;
  • Vulnerability scanning через Snyk / Dependabot / Trivy / Grype для каждого PR;
  • Container image signing через Cosign;
  • Infrastructure as Code: Terraform или Pulumi;
  • GitOps deployment: Argo CD или Flux paradigm.

5.10. Code generation toolchain (open proposal — OpenAPI-first для polyglot)​

Согласно proposal-openapi-first-polyglot-codegen.md:

  • OpenAPI 3.1 + AsyncAPI как single source of truth для всех контрактов;
  • Repository layout: /api/openapi/platform-v1.yaml, /api/openapi/partner-v1.yaml, /api/openapi/internal-v1.yaml + /api/asyncapi/*.yaml;
  • Code generation tools:
    • Go → oapi-codegen;
    • TypeScript → openapi-typescript + openapi-fetch (или openapi-typescript-codegen);
    • Python → openapi-python-client;
    • Rust → OpenAPI Generator (rust-server template);
  • Documentation portal:
    • Redoc для public partner docs (polished, SEO-friendly);
    • Swagger UI для interactive testing internal/sandbox;
  • Spectral linting с custom Vitiana rule set.

5.11. Облачный провайдер​

  • OVHcloud как первичная экосистема (выбор обоснован в operations/scaling-and-packaging-roadmap.md);
  • 4 фазы инфраструктурного масштабирования (Bootstrap → Service isolation → Workload-specific → Multi-region) с метрическими и доменными триггерами перехода (см. также operations/deployment.md, 6 execution contours);
  • Phase 1: OVHcloud Public Cloud Eco (single region, managed PostgreSQL, managed K8s, Object Storage);
  • Phase 2: cross-AZ replication для Tier 1 + Patroni + Velero для K8s backup;
  • Phase 3: secondary region cold standby для Tier 1+2;
  • Phase 4: multi-region active-active или active-passive с distributed Postgres (CockroachDB / Yugabyte) или managed multi-master.

Альтернативы (AWS, GCP, Hetzner, Azure) — допустимы при обоснованном выборе подрядчика. Все альтернативы должны соответствовать принципу открытых стандартов (4.4) и поддерживать multi-cloud DR на фазе 4 если этого потребует Enterprise клиент.

6. Функциональные требования (high-level)​

Полный список требований раскрыт в документах reference/. Этот раздел — карта по компонентам для оценки объёма работ.

6.1. По каждому компоненту​

Подрядчик оценивает (в коммерческом предложении) следующие компоненты с разбивкой по фазам:

#КомпонентГлавный документСложность
1Каноничная схема хранения и domain corereference/database-schema.md, reference/domain-model.mdВысокая
2Ingestion с multi-supplier adapter frameworkreference/ingestion.md, reference/suppliers.mdВысокая
3Offer/Quote/Booking semanticsreference/offer-pricing-booking-semantics.mdОчень высокая
4Booking State Machine (14 состояний)reference/booking-state-machine.mdВысокая
5Commercial model + dynamic pricingreference/commercial-model.md, reference/economic-model.mdВысокая
6Partner Finance & Clearingreference/partner-finance-and-clearing.mdОчень высокая
7Post-booking lifecyclereference/post-booking-lifecycle.mdВысокая
8Tour Builder доменная модельreference/tour-builder-domain.mdОчень высокая
9Tour Builder Operational (saga, drift, compensation)reference/tour-builder-operational-model.mdОчень высокая
10Tenancy + Identity модельreference/tenancy-and-identity.mdВысокая
11Multi-Tenant Isolation Strength (3 уровня)reference/multi-tenant-isolation-strength.mdВысокая
12API as Product (sandbox, DX, certification, billing)overview/platform-as-product.md, reference/api-as-product.mdВысокая
13API Metering & Usage Governancereference/api-metering-and-usage-governance.mdСредняя
14Payment Domainreference/payment-domain.mdВысокая
15Compliance & Legal infrastructurereference/compliance-and-legal.mdВысокая
16Security Architecture (IAM, encryption, secrets, audit)reference/security-architecture.mdВысокая
17Notification & Communication (multichannel + consent)reference/notification-and-communication.mdСредняя
18Data Platform & Events Tracking (6 классов событий)reference/data-platform-and-events-tracking.md, overview/data-and-intelligence-spine.mdОчень высокая
19ML Platformreference/ml-platform.mdОчень высокая
20A/B Testing frameworkreference/ab-testing-platform.mdСредняя
21Analytics & BI (internal + tenant-facing с k-anonymization)reference/analytics-and-bi.mdВысокая
22Search & Discovery (SearchProjection, RankingPolicy)reference/search-and-discovery.mdСредняя
23Media & Content pipelinereference/media-and-content.mdСредняя
24Internationalization & Localizationreference/internationalization-and-localization.mdСредняя
25Economic Model (revenue, cost, unit-economics, dynamic pricing formula)reference/economic-model.mdВысокая
26Tenant Configuration & Enablementreference/tenant-configuration-and-enablement.mdСредняя
27Offer Integrity & Publication Controlreference/offer-integrity-and-publication-control.mdСредняя
28Data Governance & Matchingreference/data-governance-and-matching.mdСредняя
29Internal Operational Surfacereference/clients.md (Surface 1), overview/layers.mdВысокая
30Agency Working Surface (Vite SPA)reference/clients.md (Surface 2)Очень высокая
31Partner Machine Surface (B2B API)reference/clients.md (Surface 3), reference/api-as-product.mdВысокая
32Partner UI/SDK Surface (@vitiana/tour-builder npm package)reference/clients.md (Surface 4)Высокая
33B2C Storefront (vitrip.store, Next.js)reference/clients.md (Surface 5)Очень высокая
34White-Label and Embedded Surfacereference/clients.md (Surface 6)Средняя
35Operational infrastructure (auto-scaling, изоляция, capacity)overview/operational-spine.md, operations/scaling-and-packaging-roadmap.md, operations/deployment.mdОчень высокая
36Observability (metrics, traces, logs, alerts, dashboards)operations/observability-and-incident-response.md, operations/observability-tooling-baseline.mdВысокая
37Release engineering (feature flags, tier-aware canary, contract testing)operations/release-engineering-and-migrations.mdВысокая
38Disaster recovery + capacity planning (4 recovery tiers)operations/disaster-recovery-and-capacity.mdВысокая
39Runbooks + on-call automation (8 incident classes)operations/runbooks-incident-playbooks.mdСредняя
40SLA Model + Service Credits + 5-уровневая on-call structureoperations/sla-and-on-call-model.mdВысокая
41Settlement & Reconciliation operationsoperations/settlement-and-reconciliation.mdСредняя
42Eventing & Queue Baseline (event bus, 6 классов событий)reference/eventing-and-queue-baseline.md, reference/initial-event-taxonomy.mdСредняя
43OpenAPI/AsyncAPI contracts package + code generationreference/api-contracts.md, proposals в development/Высокая
44Documentation governance (docs_create_section workflow, MDX safety, no destruction)development/documentation-governance.mdПостоянное
45Архитектурное руководство + tech leadershipoverview/* (все)Постоянное
46Тестирование (unit, integration, contract, e2e, performance, security, A/B canary)–Постоянное
47Compliance audit (SOC 2 Type 1 фаза 4 / Type 2 фаза 5 / ISO 27001 фаза 6)reference/compliance-and-legal.md, reference/security-architecture.mdВысокая

6.2. Подключение поставщиков​

На старте — Stuba (production-ready). На фазе 1-2 — добавление HomeToGo. На фазе 2-3 — расширение до 5+ поставщиков с разными форматами (XML, REST, GraphQL, file-based, webhooks). Архитектура должна поддерживать десятки поставщиков на фазе 3+ без существенного refactoring ядра.

Каждый новый поставщик — это:

  • ingestion adapter (нормализация в каноничную модель);
  • supplier capability profile (что умеет, какие операции, какие лимиты);
  • supplier risk class (high-trust / standard / low-trust);
  • supplier operational health monitoring;
  • mapping decisions для duplicate detection и merge с существующими canonical entities;
  • amenity mapping (из supplier-specific amenities в каноничные);
  • geo mapping (из supplier locations в каноничные);
  • product mapping (из supplier products в canonical products).

6.3. Сценарии end-to-end​

Подрядчик в коммерческом предложении должен подтвердить, что архитектура поддерживает следующие end-to-end-сценарии:

  1. Поиск и бронирование одного отеля через B2C-витрину с применением commercial policy, capture conversion events, post-booking communication.
  2. Поиск и бронирование одного отеля через Partner API с tenant-aware visibility, динамической тарификацией, webhook delivery confirmation.
  3. Создание сложного тура (multi-component) через Tour Builder с проверкой совместимости, drift handling, generation proposal artifact.
  4. Конверсия Tour Proposal в multi-booking transaction с координацией supplier confirmations, partial failures handling, atomic commitment.
  5. Cancel и amend booking с supplier coordination, refund calculation, settlement adjustment, partner balance update.
  6. Supplier disruption mid-booking (overbooking, hotel closure) с alternative search, customer communication, financial adjustment.
  7. Currency conversion в кросс-юрисдикционной транзакции (украинский клиент → чешский отель → платёж в EUR, settlement в EUR, финальный отчёт в UAH).
  8. GDPR Data Subject Request (полный экспорт + полное удаление PII клиента) с поддержанием audit trail.
  9. Partner onboarding flow от регистрации в sandbox до certification и production access.
  10. Partner billing cycle с usage aggregation, tier-based pricing, overage detection, invoice generation, payment processing.
  11. A/B test на B2C-витрине с cohort assignment, exposure tracking, statistical significance calculation, decision (ship/kill).
  12. ML model deployment для search ranking с A/B exposure нескольких версий и автоматическим rollback на деградации.
  13. Disaster recovery drill с восстановлением из geo-redundant backup в alternate region с проверкой data integrity и SLA breach calculation.

7. Нефункциональные требования​

7.1. SLA targets per tenant tier (10 каноничных SLI)​

Источник истины — operations/sla-and-on-call-model.md. Каноничные 4 SLA tier и 10 SLI metrics:

#SLI metricFreeStarterProfessionalEnterprise
1Availability per surface (uptime)best-effort95.0%99.0%99.9%+
2Latency p95 searchbest-effort<2с<1с<500мс
3Latency p95 quote creationbest-effort<3с<1.5с<800мс
4Latency p95 booking commitbest-effort<10с<5с<3с
5Webhook delivery latency p95best-effort<30с<10с<5с
6Доля unknown_external_state бронирований——менее 2%менее 1%
7Payment success rate (rejected при штатной нагрузке)—менее 5%менее 2%менее 1%
8Restoration success rate (DR drills)——95%+99%+
9MTTR (Mean Time To Recovery) для Critical incidents—best-effort<4ч<1ч
10Support response time для critical issues—1–2 business days4 business hours1 hour

Service credits при breach (см. sla-and-on-call-model.md):

  • 5% от месячной подписки при незначительном breach;
  • 10% при умеренном breach;
  • 25% при значительном breach;
  • 50% при серьёзном breach (cap).

Caнoничный flow: SLA breach detected → service credit calculated → applied to partner balance в next clearing cycle → audit log → visible через partner dashboard.

Error budget per tier с burn rate alerting и release gate: при использовании более 50% месячного error budget — release требует additional approval.

Targets — для зрелой платформы (фаза 3+). На ранних фазах — best effort с движением к target.

7.2. Scalability targets​

  • Поддержка 100K+ search calls в день на фазе 2;
  • Поддержка 1M+ search calls в день на фазе 3;
  • Поддержка 10M+ search calls в день на фазе 4;
  • Архитектура должна быть способна горизонтально масштабироваться без переписывания на каждом порядке роста.

7.3. Безопасность​

Источник истины — reference/security-architecture.md (каноничная STRIDE threat model, IAM, encryption, secret lifecycle, supply chain, audit log).

Каноничные требования:

  • STRIDE threat model (Spoofing / Tampering / Repudiation / Information Disclosure / Denial of Service / Elevation of privilege) для каждого нового feature;
  • IAM (Identity and Access Management): RBAC + ABAC hybrid с тонкой гранулярностью; capability set resolver GET /capability/me;
  • Authentication levels — Level 1 (single factor — basic users), Level 2 (MFA — все privileged users + payment actions), Level 3 (step-up re-auth для sensitive operations: refund > €1000, account deletion, role grants);
  • Token model — JWT access tokens TTL ≤ 1 час, opaque refresh tokens TTL 30 дней с rotation, service account keys с automated rotation 90 дней;
  • Mutual TLS (mTLS) для service-to-service с фазы 3+ (service mesh — Istio или Linkerd);
  • Encryption at-rest через TDE + column-level encryption для sensitive PII; per-tenant keys (CMK) для Enterprise;
  • Encryption in-transit: TLS 1.3 mandatory для external endpoints;
  • Automated key rotation: master keys annual, DEKs 90 дней, application secrets 90 дней (long-lived) или per-use (short-lived);
  • Scoped API keys с environment binding (sandbox vs production);
  • Secret management через HashiCorp Vault (фаза 2+) или SOPS на bootstrap;
  • WAF (Cloudflare / OVHcloud / ModSecurity) для публичных поверхностей;
  • DDoS protection (OVHcloud Anti-DDoS baseline + Cloudflare на edge);
  • Supply chain security: SBOM generation для каждого release, vulnerability scanning (Snyk / Dependabot / Trivy), code signing (GPG / Cosign), trusted base images (distroless);
  • Container security: read-only root filesystem, non-root user, no privileged containers, dropped capabilities, Seccomp profiles;
  • Comprehensive audit logging в immutable WORM storage (отдельный stack от operational observability) — Tier 1 retention 7 лет с tamper detection через hash chains;
  • Penetration testing: external annual с фазы 3, semi-annual с фазы 5;
  • Bug bounty: private program HackerOne / Bugcrowd с фазы 4, public с фазы 5;
  • SLA на patching: Critical 24 часа, High 7 дней, Medium 30 дней, Low 90 дней;
  • Compliance аудиты: SOC 2 Type 1 фаза 4 (Enterprise tier requirement), SOC 2 Type 2 фаза 5, ISO 27001 фаза 6;
  • 5 каноничных compromise scenarios с recovery procedures (compromised user account / compromised service account / compromised production database / supply chain compromise / cross-tenant data leakage).

7.4. Privacy и data protection​

Источник истины — reference/compliance-and-legal.md.

  • GDPR-by-design в каждом компоненте;
  • data_field_inventory с lawful basis per поле (consent / contract / legal obligation / vital interests / public task / legitimate interests);
  • Минимизация PII в захвате данных;
  • Анонимизация на уровне захвата tracking events (хешированные user IDs, обобщённая геолокация);
  • Retention discipline с автоматическим удалением (booking_data 7 лет, audit_log 2 года, analytics_aggregated 2 года, analytics_individual 90 дней с k-anonymization после, marketing_consent пока active + 3 года);
  • Audit trail каждого доступа к PII (data.sensitive.accessed event в immutable storage);
  • Cross-border transfer mechanisms: Standard Contractual Clauses (SCCs) UA↔EU, KZ↔EU; KZ data localization (mandatory dedicated_infrastructure для KZ residents);
  • Каноничный DSR API (Data Subject Rights):
    • GET /privacy/data-export?subject_id={...} (Right of Access + Portability);
    • PATCH /privacy/data-correct (Right to Rectification);
    • POST /privacy/data-delete (Right to Erasure);
    • POST /privacy/processing-restrict (Right to Restrict Processing);
    • POST /privacy/processing-object (Right to Object);
    • SLA на ответ: 30 дней (legal max), цель 7 дней;
  • Privacy Impact Assessment (PIA) для high-risk processing (automated decision-making с legal effect, large-scale tracking);
  • Privacy review каждого feature до production deployment;
  • Breach notification: 72 часа на supervisory authority, без неоправданной задержки на affected Data Subjects при high risk;
  • Cookie Directive (ePrivacy): Consent Management Platform (CMP — Cookiebot / OneTrust / собственная);
  • Data Processing Agreement (DPA) signed со всеми processors (PSP, cloud, SaaS) до любого data flow;
  • Sub-processor disclosure публично доступна;
  • DPO (Data Protection Officer) на фазе 6 при достижении threshold.

7.5. Reliability​

Источник истины — operations/disaster-recovery-and-capacity.md, operations/sla-and-on-call-model.md, operations/runbooks-incident-playbooks.md.

  • Идемпотентность всех critical mutation-операций (с client-supplied idempotency keys);
  • Replay safety всех async consumers;
  • Backpressure discipline на async очередях;
  • Circuit breakers на критических точках вызовов внешних систем (поставщики, PSP);
  • Graceful degradation при перегрузке: rate limiting per tenant, отключение non-critical features через feature flags, замедление batch jobs, cache-only режим для search queries;
  • Multi-region active-active для read paths на фазе 4;
  • Multi-region active-passive для write paths на фазе 4 с явной consistency model (distributed Postgres — CockroachDB / Yugabyte или managed multi-master);
  • 4 каноничных recovery tiers с RTO/RPO:
    • Tier 1 (Payment, Booking, Audit log, User/Tenant, RevenueRecord): RTO 60м, RPO 5м, 7 лет retention, ежемесячный partial restore + ежеквартальный full restore drill;
    • Tier 2 (Offer, Quote, Search projection, Notifications): RTO 4ч, RPO 30м;
    • Tier 3 (Analytics, ML feature store, Logs): RTO 24ч, RPO 1ч;
    • Tier 4 (Archived): RTO 7д.
  • 8 каноничных incident classes с runbooks и автоматизированными процедурами;
  • Burnout protection: не более 1 недели on-call per engineer per 4–8 weeks (фазо-зависимо).

7.6. Maintainability​

  • Domain-Driven Design с явными bounded contexts;
  • Hexagonal architecture (ports & adapters);
  • Code review для каждого pull request;
  • Automated tests: unit (80%+ coverage on domain core), integration, contract, end-to-end, performance;
  • Documentation: каждый сервис имеет actionable README, OpenAPI/AsyncAPI specs для всех contracts, ADR (Architecture Decision Records) для нетривиальных решений;
  • Onboarding нового разработчика — < 2 weeks до первого продуктивного PR.

7.7. Performance​

  • Cache hit ratio для read paths > 85% на B2C-витрине;
  • Database query latency p95 < 50ms для canonical reads;
  • Database query latency p95 < 200ms для transactional writes;
  • Search query latency p95 < 500ms для типичных запросов;
  • API gateway overhead < 10ms p95.

8. Фазы реализации​

Полное описание — в operations/scaling-and-packaging-roadmap.md. Краткая карта:

Фаза 1 — Bootstrap (controlled internal platform)​

Длительность ориентировочно: 0-12 месяцев от старта.

Главные deliverables (приоритет 1 — критические gaps стадии 1 implementation baseline):

  • Multi-tenancy migration — tenant_id во все таблицы существующего apivitianadb; RLS policies; начало IsolationBoundaryCheck (logical уровень изоляции);
  • Booking state machine миграция — 14 каноничных состояний с обработкой unknown_external_state;
  • Payment domain — выбор PSP (Stripe рекомендуется), PaymentIntent flow, refund baseline, никакого card data на серверах Vitiana (PCI DSS SAQ A через PSP);
  • Compliance baseline — privacy notice, consent management, DSR API minimal viable (GET /privacy/data-export, POST /privacy/data-delete), retention policies enforcement, data_field_inventory с lawful basis;
  • Security baseline — MFA mandatory для admin (Level 2), secrets manager (SOPS bootstrap), audit logging baseline в immutable storage, encryption at-rest + in-transit;
  • DR baseline для Tier 1 — verified backup и restore процедура для критических данных (booking, payment, audit log).

Главные deliverables (приоритет 2 — controlled internal platform):

  • развёрнута новая dev-инфраструктура на OVHcloud Public Cloud Eco (managed Kubernetes, managed PostgreSQL, Object Storage, vRack);
  • реализован прототип каноничной модели с разделением canonical / supplier-derived / operational entities;
  • адаптер Stuba переписан для работы с каноничной моделью (dual-write с существующим apivitianadb);
  • прототип адаптера HomeToGo (доказательство правила 00000 — равноправное подключение второго supplier);
  • базовый Offer Service с persistent storage;
  • базовый Quote Service;
  • Booking Service с 14 каноничными состояниями;
  • базовая Tour Builder функциональность с composition primitives;
  • Notification service — каноничный multichannel вместо ad-hoc email через PHP backend;
  • Search service — выделение от прямых SQL queries, PostgreSQL FTS minimum;
  • Event store baseline — Redis Streams для domain events;
  • API as Product partner lifecycle — sandbox + certification minimum для второго supplier;
  • Media abstraction — каноничный MediaAsset model;
  • i18n baseline — SupportedLanguage / SupportedCurrency / FX rates;
  • Frontend B2C (vitrip.store) — Next.js 15 App Router (новые pages); existing Preact + HTM остаётся для базовых до миграции (Strangler Fig pattern);
  • Frontend admin / Tour Builder — Vite + React SPA + TanStack Router; design system как npm package @vitiana/ui;
  • Backend baseline — TypeScript primary + Go для performance-critical (см. раздел 5.1);
  • Observability — Prometheus + Grafana + Loki + Tempo;
  • CI/CD pipeline — GitHub Actions / GitLab CI + signed commits + SBOM generation + vulnerability scanning;
  • Базовая documentation для команды + соблюдение development/documentation-governance.md;
  • SLA Free tier (best-effort) держится за 90 дней.

Триггеры выхода в фазу 2:

  • регулярное превышение использования CPU/RAM на dev-инфраструктуре;
  • подключён реальный поток данных от второго поставщика (HomeToGo) в production-режиме;
  • первые внешние партнёры активировали API-доступ (даже на бесплатном уровне);
  • запущен production-режим хотя бы одного из основных контуров;
  • команда расширилась до 5+ инженеров.

Фаза 2 — Service isolation (controlled external beta)​

Длительность ориентировочно: 12-24 месяцев от старта.

Главные deliverables:

  • Cross-AZ replication для Tier 1 (Patroni для PostgreSQL, Velero для K8s backup);
  • Automated daily test restore для Tier 1 в изолированный namespace + ежемесячные partial restore drills;
  • HashiCorp Vault (миграция с SOPS) с automated secret rotation 90 дней;
  • разделение execution contours на отдельные Bare Metal Advance nodes (или эквивалент);
  • managed Kafka (или NATS Jetstream) для domain events;
  • Meilisearch (или эквивалент) для polished search (миграция с PostgreSQL FTS);
  • managed observability stack (Prometheus, Loki, Tempo) + Pyrra/Sloth для SLI/SLO calculation;
  • formal release engineering: feature flags, tier-aware canary (Enterprise — first canary), contract testing, migration discipline, error budget gate;
  • 5-уровневая on-call structure (Primary → Secondary → Engineering Manager → Director/VP → CTO/CISO) — формализована;
  • Burnout protection — не более 1 недели on-call per engineer per 4–6 weeks;
  • Runbooks для всех 8 каноничных incident classes (см. operations/runbooks-incident-playbooks.md);
  • Status page (Statuspage.io / Atlassian Statuspage / собственная);
  • Tenant-facing SLA dashboards (базовая версия) с показателями actual uptime, latency, webhook delivery;
  • Partner API Surface stabilized с sandbox + certification flow;
  • self-service partner onboarding;
  • 3-5 active платных партнёров на Starter / Professional tier;
  • Tour Builder operational model в beta — saga, drift detection, compensation;
  • Tour Builder partner-grade UI/SDK — npm package @vitiana/tour-builder доступен для Professional+ tier;
  • formal SLA introduction (Starter 95% и Professional 99% tier с service credits formula);
  • managed PostgreSQL Business + read replicas;
  • Payment domain integration с PSP (Stripe или альтернатива по выбору на стадии 1) — full PaymentIntent lifecycle, refund, chargeback workflow;
  • Compliance infrastructure:
    • GDPR DSR workflow полный (все 5 каноничных endpoints);
    • PSD2 SCA через PSP;
    • PCI scope minimization (SAQ A);
    • basic Package Travel Directive support для tour bookings;
    • cookie consent management (CMP);
    • DPA management для всех data processors;
  • Privacy review обязателен для каждого нового feature до production deployment;
  • Initial ML use cases: anomaly detection в ingestion, search ranking прототип;
  • A/B testing framework базовая реализация (feature flags + cohort assignment + exposure tracking);
  • Internal SIEM (Wazuh / Datadog Security) — отдельный stack от operational observability;
  • mTLS (опционально) для critical service-to-service paths;
  • dual-write миграция от старого apivitianadb к новой каноничной БД (read paths переключены);
  • DWH baseline — DuckDB или ClickHouse single-node;
  • Domain events vs analytical events разделение (Долг 8 закрыт);
  • unknown_external_state ratio < 2% держится за 90 дней (target Professional);
  • SLA Starter (95%) держится за 90 дней без серьёзных breaches.

Триггеры выхода в фазу 3:

  • один партнёр стабильно создаёт нагрузку, влияющую на других;
  • объём событий взаиморасчётов превышает обработку базового кластера;
  • приём данных от 5+ поставщиков с разными SLA;
  • появление премиум-партнёров, требующих гарантированной полосы;
  • регуляторные требования к локализации данных для отдельных стран;
  • объём бронирований превышает порог shared-infrastructure комфорта.

Фаза 3 — Workload-specific packaging (production-capable)​

Длительность ориентировочно: 24-36 месяцев от старта.

Главные deliverables:

  • Bare Metal Scale для критического ядра в Strasbourg;
  • Eco Rise XL для тяжёлых ingestion workers;
  • Dedicated GPU pools для ML inference;
  • Secondary region cold standby для Tier 1+2 (logical replication);
  • Cross-region replication Object Storage;
  • DNS failover через Cloudflare (или эквивалент) с automated health check;
  • managed PostgreSQL Enterprise + read replicas;
  • managed Kafka Production cluster (или NATS Jetstream);
  • Elasticsearch / OpenSearch Production (миграция с Meilisearch при необходимости);
  • managed ClickHouse cluster для аналитики;
  • AI Training, AI Deploy, AI Endpoints — production ML platform;
  • feature store (Feast — open-source self-hosted или Tecton commercial);
  • model registry (MLflow);
  • model serving infrastructure (TorchServe, Triton или эквивалент);
  • зрелый A/B testing framework;
  • Partner-facing analytics product (Professional+ tier) с k-anonymization для cross-tenant comparisons;
  • streaming pipeline (Kafka Streams или Flink);
  • Bare Metal Storage для cold archive (Tier 4);
  • Dedicated_compute isolation level доступен для tenant Professional+ (опционально);
  • 24/7 on-call rotation с follow-the-sun (3 региона);
  • Burnout protection — не более 1 недели per SRE per 6–8 weeks;
  • Runbooks для всех 8 каноничных incident classes в production-grade состоянии + runbook automation через ChatOps;
  • Formal post-mortem culture — обязательны для все major incidents;
  • Production-grade DR:
    • ежеквартальный full restore drill для Tier 1+2;
    • ежеквартальный region failover drill;
    • automated chaos drills через Chaos Mesh;
  • Tier 1 RTO 60м / RPO 5м, Tier 2 RTO 4ч / RPO 30м держатся за 180 дней;
  • AI-powered observability (anomaly detection, predictive alerting);
  • First Rust services для critical paths по metrics:
    • pricing-engine (Tour Builder real-time pricing);
    • search-orchestrator (поиск с aggregation от множества suppliers);
    • saga-coordinator (Tour Builder transactions);
  • Service mesh (Istio или Linkerd) с full mTLS;
  • External penetration testing (annual);
  • Private bug bounty (HackerOne / Bugcrowd);
  • Enterprise tier introduced (99.9%+ SLA с custom RTO/RPO в контракте);
  • write paths переключены на каноничную БД, старая apivitianadb deprecated;
  • vitrip.store сайт полностью на canonical model;
  • Partner API Surface launched как платный продукт с full lifecycle (sandbox → certification → production);
  • Tour Builder Closed Surface launched (paid Tour Builder tier);
  • Agency Working Surface launched (отдельный Vite SPA);
  • Partner UI/SDK — @vitiana/tour-builder npm package в production использование;
  • 30+ active платных партнёров (Starter / Professional / первые Enterprise);
  • ML use cases в production: search ranking, recommendation, anomaly detection в ingestion, partner risk scoring, fraud detection;
  • unknown_external_state ratio < 1% держится за 180 дней (target Enterprise);
  • SLA Professional (99%) держится за 180 дней с automated service credits применением;
  • First Enterprise contract в production;
  • Public bug bounty consideration в конце фазы.

Триггеры выхода в фазу 4:

  • регуляторные требования к data residency одновременно для нескольких юрисдикций;
  • сертификационные требования enterprise-класса (ISO 27001, SOC 2 Type II);
  • подписание enterprise-контракта с партнёром, требующим выделенной инфраструктуры;
  • объём входящего трафика превышает возможности одного региона;
  • глобальное распределение пользователей требует низкой задержки в нескольких регионах одновременно;
  • бизнес-непрерывность требует geo-redundancy с контролируемым переключением.

Фаза 4 — Multi-region и dedicated infrastructure​

Длительность ориентировочно: 36+ месяцев от старта (продолжается долгосрочно).

Главные deliverables:

  • Multi-region active-active или active-passive с автоматическим failover;
  • Distributed Postgres (CockroachDB / Yugabyte) или managed multi-master для cross-region writes;
  • Bare Metal High Grade в Paris с 3-AZ deployment для booking commit;
  • multi-region read paths (Strasbourg + Warsaw + Frankfurt + опционально другие регионы);
  • GeoDNS с автоматическим failover и health check;
  • Dedicated_infrastructure isolation level для Enterprise tenants (mandatory для regulated клиентов);
  • Regional data residency для регулируемых юрисдикций (GDPR data в EU regions, KZ data в KZ-region — обязательно для KZ residents согласно Закону РК);
  • edge compute через Local Zones / Cloudflare Workers (или эквивалент);
  • multi-region observability с federation;
  • multi-region SIEM;
  • Formal compliance аудиты:
    • SOC 2 Type 1 пройден на старте фазы 4;
    • SOC 2 Type 2 в процессе достижения (continuous audit);
  • ISO 27001 consideration в конце фазы 4 / начало фазы 5–6;
  • Enterprise-grade DR:
    • RTO < 1 hour, RPO < 15 minutes для Enterprise tier;
    • ежемесячные chaos drills (отключение целого региона);
    • automated DR drill scheduling и execution;
  • Расширение в Германию, Австрию, Балтику или other EU markets с локализацией;
  • Capability marketplace add-ons как дополнительный revenue stream:
    • доступ к premium-поставщикам;
    • extended ML capabilities (custom ranking, custom recommendation);
    • special geographies или сегменты inventory;
    • premium support (24/7 phone);
    • compliance services (DPO consultation, audit support);
  • AML / KYC для high-volume transactions (через Onfido / Sumsub / Veriff partnership);
  • ML use cases расширены: dynamic pricing, conversion optimization, fraud detection, content moderation, demand forecasting, Tour Builder compatibility scoring, supplier health prediction; AI-based capacity prediction;
  • Privacy-preserving ML консидерация: differential privacy для cross-tenant features, federated learning для regulated tenants;
  • Public bug bounty программа (HackerOne / Bugcrowd public);
  • Premium support (24/7 phone) для Enterprise tier;
  • Multi-cloud DR consideration при Enterprise клиенте с такими требованиями;
  • DPO (Data Protection Officer) hire (mandatory при достижении threshold);
  • Continuous penetration testing (semi-annual);
  • 5-уровневая on-call structure в полном составе с regional teams (follow-the-sun);
  • 50+ active платных партнёров с растущей долей Enterprise;
  • unknown_external_state ratio < 0.5% target для Enterprise;
  • SLA Enterprise (99.9%) держится за 365 дней с automated service credits;
  • MTTR Critical < 1 hour для Enterprise.

9. Команда и роли​

Подрядчик предлагает свой состав команды на основе scope работ. Каноничный план — в development/team-and-staffing-plan.md (модель ролей и роста команды по 7 стадиям зрелости с триггерами).

Главный принцип: hiring запускается по триггерам стадий зрелости, не по календарю. Lead time на senior — 8–16 недель; на специалиста (SRE, compliance) — 12–24 недели. Поэтому при достижении 70% triggers стадии — открытие позиций на следующую стадию немедленно.

9.1. Ключевые роли по фазам​

РольPhase 1Phase 2Phase 3Phase 4+УровеньГлавные обязанности
Tech Lead / Architect (CTO equivalent)111 + Director of Engineering1 + VP EngineeringSenior+ (10+ лет)Архитектурное руководство, технические решения, code review критических компонентов, communication с заказчиком, утверждение canonical документов
Engineering Manager—12-33-5SeniorPeople management, sprints, code review, on-call escalation
Backend Engineer (TypeScript primary)2-34-66-88-12Mid+ to SeniorРеализация domain core, Offer/Quote/Booking services, Partner API, Internal services, BFF
Backend Engineer (Go)1-23-45-77-10Mid+ to SeniorPerformance-critical services, search, ingestion, payment, settlement
Backend Engineer (Rust)001-22-3Senior (с crypto/fintech background желателен)С фазы 3 только: pricing-engine, search-orchestrator, saga-coordinator. Не нанимать на фазах 1-2 — pool узкий, преждевременно
Frontend Engineer (Next.js / React)12-33-55-7Mid+ to SeniorB2C витрина (vitrip.store, Next.js), partner developer portal (Next.js)
Frontend Engineer (Vite SPA, Tour Builder)123-45-7Mid+ to SeniorAgency working surface (Vite SPA), Tour Builder UI/SDK, internal operational surface
Data Engineer—12-32-3SeniorEvents tracking, DWH (DuckDB/ClickHouse), ETL/streaming pipelines, data quality
ML Engineer—— или 0.251-22-3SeniorТолько с фазы 3+: feature store, model registry, model serving, ML use cases. Не нанимать на фазах 1-2
Data Scientists———1-2SeniorML use cases, A/B analysis (только Phase 4+)
SRE / DevOps engineer123-5 (formation of SRE team)5+ (SRE team с regional follow-the-sun)SeniorInfrastructure as Code, CI/CD, observability stack, capacity planning, DR drills, runbook automation
Platform / Infrastructure engineer—12-33-5SeniorPhase 1→2→3→4 infrastructure transitions, K8s, service mesh, multi-region
Database Administrator0.5 (часть DevOps)11-21-2SeniorSchema migrations, performance tuning, backup/restore, DR drills, multi-region replication
Product Manager / Director of Product1 PM1 PM1 PM + 1 Director of Product2-3 PMs + DirectorSeniorRequirements, prioritization, partner stakeholder communication
QA / SDET Engineer—12-33-4Mid+Test automation, performance testing, security testing, browser testing
Security Engineer—0.51 (full-time)2-3 (formation security team + CISO на фазе 5–6)SeniorThreat model, security review, vulnerability management, audit evidence для SOC 2 / ISO 27001, secret lifecycle
Compliance Officer——1 (part-time, может быть external)1 full-time + DPO на фазе 6SeniorGDPR / PSD2 / TOMS / Package Travel, audit evidence, DPA management, DSR coordination
Customer Success Manager (Enterprise)———1+SeniorProactive Enterprise tenant engagement, 24/7 escalation, contract renewal
Partner Success Manager—11-22-3Senior (non-junior!)Proactive partner engagement, certification support, partner roadmap alignment
Customer Support specialists—12-33-5Mid+Tier-зависимый support
Technical Writer0.25 (consultative)0.51 (full-time)2Mid+API documentation (partner-facing developer documentation), internal runbooks, SOC 2 audit evidence

Цифры дробные означают part-time или consulting engagement.

Важное (изменения от первой версии ТЗ):

  • Rust перенесён с фазы 1 на фазу 3 — на бутстрапе (4–8 человек) Rust-инженер преждевременен; pool узкий, lead time hire 12–24 недели; стратегия — Strangler Fig: Rust для critical paths по metrics-driven justification на фазе 3+;
  • Backend baseline pivot — вместо «Go primary + Rust secondary» каноничный путь «TypeScript primary + Go для performance-critical» (см. раздел 5.1) с Rust как фаза 3+ extension;
  • ML Engineer перенесён на фазу 3+ — pool ML-инженеров узкий, hiring дорог; на ранних фазах consultative / external sufficient;
  • Compliance Officer и Security Engineer как first-class roles с фазы 3 (не «через юр. фирму ad-hoc»);
  • Partner Success как first-class функция с фазы 2 — не часть sales/business team.

9.2. Требования к команде​

  • Все senior-роли — англо- или русскоговорящие (общение с заказчиком на русском);
  • Опыт зрелых B2B SaaS-платформ — обязателен для Tech Lead, Architect, senior backend;
  • Опыт travel-индустрии — желателен, не обязателен;
  • Опыт DDD, event sourcing, hexagonal architecture — обязателен для Tech Lead;
  • Опыт production-grade ML platforms (фаза 3+) — обязателен для ML Engineer;
  • Опыт production-grade PostgreSQL (включая partitioning, replication, multi-region) — обязателен для DBA;
  • Опыт OVHcloud / managed K8s — желателен для DevOps / SRE;
  • Опыт regulatory compliance (GDPR, PSD2, PCI DSS, SOC 2) — обязателен для Security Engineer и Compliance Officer;
  • Опыт saga pattern / distributed transactions — обязателен для backend engineers, работающих с Tour Builder (фаза 2+);
  • Опыт OpenAPI 3.1 / AsyncAPI / code generation toolchains — желателен для всех backend и frontend engineers;
  • Опыт Next.js 15 App Router (Server Components, Server Actions) — желателен для frontend B2C engineers;
  • Опыт Vite + React SPA + TanStack Router — желателен для frontend admin/Tour Builder engineers;
  • Опыт Diversity hiring practices — обязательны с фазы 4 (gender, nationality, educational background diversity).

9.3. Distributed vs co-located​

Распределённая (remote-first) команда допустима. Несколько часовых поясов допустимы при соблюдении:

  • ежедневный sync (минимум одна группа на 4 часа overlap);
  • async-first communication (decisions documented in writing);
  • formal sprint planning и review.

10. Критерии приёмки (acceptance criteria) per фаза​

10.1. Общие критерии для каждой фазы​

  • ✅ Все deliverables фазы реализованы;
  • ✅ Code coverage по unit tests ≥ 80% для domain core;
  • ✅ Code coverage по integration tests ≥ 60% для критических flows;
  • ✅ Все contracts (OpenAPI/AsyncAPI/gRPC) имеют contract tests;
  • ✅ End-to-end tests покрывают все сценарии раздела 6.3;
  • ✅ Performance tests подтверждают SLA targets для целевой фазы;
  • ✅ Security audit (минимум базовый OWASP Top 10) пройден;
  • ✅ Documentation актуальна: каждый сервис имеет README, OpenAPI/AsyncAPI specs обновлены, ADR для нетривиальных решений;
  • ✅ CI/CD pipeline работает для всех сервисов;
  • ✅ Observability dashboards настроены;
  • ✅ Runbooks для критических инцидентов фазы написаны;
  • ✅ Code review pass для всех PR;
  • ✅ Архитектурное соответствие: проверка на соответствие 6 осям и принципам разработки (раздел 4).

10.2. Специфические критерии per фаза​

Фаза 1:

  • Адаптер Stuba переписан для работы с каноничной моделью без потери production-функциональности;
  • Прототип адаптера HomeToGo демонстрирует независимость каноничной модели от структур поставщика;
  • Базовый booking flow работает на dev-инфраструктуре с реальными данными от Stuba;
  • Базовый Tour Builder создаёт composition с минимум 2 разными типами модулей.

Фаза 2:

  • Partner API Surface отделён от ingestion (никаких следов «Stuba endpoint» как Partner API);
  • 3 платных партнёра завершили certification и активны в production;
  • Tour Builder поддерживает все 8 типов модулей (accommodation, transfer, activity, service, transport, insurance, custom, informational);
  • SLA Starter (99.0%) и Professional (99.5%) выполняются ≥ 95% времени;
  • Compliance baseline: GDPR DSR workflow работает, Package Travel Directive disclosure для туров EU реализована.

Фаза 3:

  • Enterprise tier SLA (99.9%) выполняется;
  • 30+ active платных партнёров;
  • ML use cases в production (search ranking, anomaly detection в ingestion);
  • Partner-facing analytics product доступен для Professional+ тарифов;
  • DR drill пройден успешно с RTO < 4 hours, RPO < 1 hour;
  • Старая apivitianadb deprecated, vitrip.store на canonical model.

Фаза 4:

  • Multi-region read-paths active-active работает с failover testing пройден;
  • 1+ Enterprise contract с dedicated infrastructure активен;
  • SOC 2 Type II audit пройден;
  • Расширение в минимум одну новую географию (Германия, Австрия или другая);
  • Capability marketplace add-ons активны.

11. Формат сотрудничества​

11.1. Возможные модели​

Подрядчик предлагает одну или несколько моделей:

  • Time and Materials (T&M): ставка час × отработанные часы, ежемесячная фактура. Применима для длительных engagements с эволюционирующими requirements. Прогноз бюджета — на основе capacity и плановых person-months.
  • Fixed Price per Phase: фиксированная цена за каждую фазу с явными deliverables и acceptance criteria. Подходит для phases с чётко определённым scope. Риск изменения scope — на стороне заказчика (change request workflow).
  • Hybrid: фиксированная цена за core deliverables + T&M на дополнительные требования и итерации.
  • Milestone-based: оплата по достижению ключевых milestones внутри фазы.

Заказчик готов рассматривать любую из моделей при адекватном обосновании со стороны подрядчика. Предпочтение — Hybrid с понятным scope контролем.

11.2. Управление изменениями​

  • Все изменения scope формализуются как Change Requests с обоснованием, оценкой влияния на сроки и бюджет;
  • Архитектурные решения принимаются совместно (заказчик ↔ подрядчик) с документированием в ADR;
  • Каждый sprint review включает demo и принятие или возврат на доработку;
  • Каждое окончание фазы — formal acceptance с подписанием Acceptance Document.

11.3. Коммуникация​

  • Daily standup внутри команды подрядчика;
  • Weekly sync с заказчиком (минимум 1 час);
  • Monthly executive review (full team + decision-makers заказчика);
  • Async communication — в Slack/Teams + Email для formal decisions;
  • Все important decisions документируются (ADR, Confluence или эквивалент).

11.4. Source code и intellectual property​

  • Source code принадлежит заказчику с момента создания;
  • Repository — на стороне заказчика (GitHub, GitLab или эквивалент) с доступом подрядчика;
  • Intellectual property всех артефактов (код, документация, диаграммы, миграционные скрипты) — на стороне заказчика;
  • Подрядчик может использовать generic patterns и open-source contributions, но ничего специфичного для платформы Vitiana.

11.5. Tech transfer и handover​

  • На каждой фазе подрядчик обеспечивает knowledge transfer любому новому подрядчику или собственной команде заказчика;
  • Документация всегда up-to-date;
  • На завершении сотрудничества — формальный handover с onboarding нового team в течение 2-4 недель paid.

12. Открытые развилки и неопределённости​

Эти вопросы будут уточняться совместно с заказчиком и future Tech Lead на стадии 1 implementation baseline. Подрядчик в коммерческом предложении явно обозначает, как трактует каждый вопрос.

12.1. Архитектурные (часть зафиксирована в open proposals — см. указанные документы)​

  • Backend language baseline — TypeScript primary + Go vs Go primary + Rust radical performance-first. Каноничная рекомендация: TypeScript + Go на фазе 1, Rust для critical paths на фазе 3+. См. development/proposal-stack-roadmap-by-product-tier.md, development/proposal-stack-detailed-discussion-russian.md;
  • Frontend split — единый Next.js for everything vs Next.js (B2C) + Vite SPA (admin/Tour Builder). Каноничная рекомендация: split, см. proposal-stack-detailed-discussion-russian с обоснованием 6 причин;
  • OpenAPI-first для polyglot — single source of truth + code generation toolchain (oapi-codegen / OpenAPI Generator / Spectral) — см. development/proposal-openapi-first-polyglot-codegen.md;
  • Strangler Fig migration для перехода от home-to-go-api к canonical model — параллельная разработка с dual-write, не полный рефакторинг. См. overview/relation-to-implementation-baseline.md;
  • Geographic distribution команд на фазе 5+ — Прага / Варшава / Алматы / Берлин или другое сочетание;
  • 3-AZ Paris для booking commit или multi-region active-active без 3-AZ? Решение в фазе 4 на основе latency metrics;
  • Distributed Postgres для multi-region (CockroachDB / Yugabyte / managed multi-master) на фазе 4;
  • Self-hosted vs managed PostgreSQL Enterprise на фазах 3-4? Зависит от cost analysis;
  • Search engine — миграция PostgreSQL FTS → Meilisearch → Elasticsearch — конкретные timing решений;
  • Event bus — Redis Streams (Phase 1) → NATS Jetstream vs Kafka (Phase 3+);
  • DWH — DuckDB / ClickHouse self-hosted vs managed (BigQuery / Snowflake) на фазе 4–5 по economics;
  • Cloud GPU vs dedicated GPU для ML на фазе 4+;
  • Build vs Buy для ML platform (Tecton commercial vs Feast open-source);
  • Build vs Buy для A/B testing framework (LaunchDarkly vs Unleash vs собственная);
  • Multi-cloud DR на фазе 4 (AWS как backup для OVHcloud) при появлении Enterprise клиента с такими требованиями;
  • Mobile strategy для Surface 5 (B2C) — PWA (фаза 3) vs native iOS/Android (фаза 5+);
  • SDK strategy для партнёров — single TypeScript SDK + auto-generated для остальных vs full per-language SDKs;
  • GraphQL gateway на фазе 5+ при росте frontend teams.

12.2. Бизнесовые​

  • Точные envelope каждого тарифного уровня (search calls, quotes, bookings) — финализируется на стадии 1 совместно с product team. См. reference/api-as-product.md;
  • Точная dynamic pricing formula для платформенных услуг — финализируется на стадии 1 в рамках economic-model;
  • Pricing model для Enterprise: subscription + usage vs revenue-share vs fixed price vs hybrid — custom contract per Enterprise tenant;
  • Tour Builder как отдельный subscription или add-on к Professional — финализируется на стадии 1;
  • Capability marketplace add-ons (premium suppliers, extended ML, premium support, compliance services) — финализируется на фазе 4;
  • White-label стратегия для B2C broader: через Partner API + UI components (deep customization) vs отдельная white-label платформа;
  • Open marketplace третьих интеграций — стадия 5 или 6.

12.3. Регуляторные​

  • Точная модель merchant-of-record для каждого tenant tier и страны — гибридная per-tenant base, финализируется по контракту с каждым партнёром;
  • PSP selection: Stripe (US-headquartered, EU subsidiary, broad), Adyen (NL, enterprise-grade), Mollie (NL, EU-only), Multi-PSP adapter с фазы 1. Каноничная рекомендация — начать со Stripe + abstraction layer для multi-PSP на фазе 3+;
  • EU member state of establishment для VAT registration (CZ — где OVHcloud datacenter, или DE — больший талант pool) — решение на стадии 3 совместно с tax counsel;
  • Insolvency protection mechanism для Package Travel Directive (страховой полис, банковская гарантия, escrow account) — фаза 3;
  • KZ data localization strategy — полная localization в KZ region (фаза 4) vs separate legal entity in KZ vs avoid KZ regulated channels — решение на стадии 3;
  • AML/KYC threshold и vendor selection (Onfido / Sumsub / Veriff) — фаза 4;
  • DPO (Data Protection Officer) timing — при каком объёме данных или employees DPO становится mandatory — решение на стадии 4 с external counsel;
  • California / US compliance при US expansion (CCPA / CPRA + state-specific laws) — стадия 5+;
  • ADR (Architecture Decision Records) формат — текущая модель тезисное обоснование внутри документов; альтернатива — отдельные ADR-документы — решение по результатам стадии 2;
  • Public DocMap publication — когда открывать DocMap наружу как часть partner experience (стадия 3).

12.4. Команда и темп​

  • Темп найма (hiring pace) на стороне подрядчика;
  • Реальная availability senior инженеров — особенно Rust (узкий pool в EU/CIS), ML, Compliance Officer, Security Engineer;
  • Распределение между восточно-европейской и западной командами (если применимо);
  • Возможность дополнительных контракторов на пиковых нагрузках (фазы 2-3);
  • Internal mobility приоритет над external hiring — для новых ролей при достижении триггера;
  • Contractor-to-FTE conversion для специалистов (compliance officer, security, technical writer, ML scientist) на ранних фазах;
  • EM vs Tech Lead разделение — на каких стадиях разделять (EM = people management, TL = technical leadership) — решение на стадии 3.

См. также development/team-and-staffing-plan.md — каноничный план команды по 7 стадиям зрелости.

13. Что подрядчик предоставляет в коммерческом предложении​

Подрядчик в ответ на это ТЗ предоставляет:

13.1. Главное​

  1. Понимание scope — резюме того, как подрядчик понимает scope (с явным указанием trade-off, которые он видит);
  2. Команда — состав команды per фаза с резюме ключевых членов и обоснованием их выбора;
  3. Технологический стек — окончательный выбор стека с обоснованием (особенно если отличается от рекомендации);
  4. План реализации по фазам — с разбивкой по компонентам, deliverables, рискам, зависимостям;
  5. Бюджет — детальная разбивка по фазам, компонентам, ролям, моделям сотрудничества;
  6. Сроки — с явными milestones и triggers перехода между фазами;
  7. Модель сотрудничества — выбранная (T&M / Fixed / Hybrid / Milestone-based) с обоснованием;
  8. Управление рисками — риск-реестр с identified risks, impact, mitigation strategies, contingency budget.

13.2. Дополнительно​

  1. Архитектурное диаграммирование — high-level диаграммы предлагаемого решения (компонентные, deployment, data flow);
  2. Sample ADR — пример Architecture Decision Record для одного из критических решений (например, выбор между event sourcing и traditional state machine для Booking lifecycle);
  3. Обработка ингестона существующего home-to-go-api — конкретный план миграции с timeline и сохранением production-функциональности;
  4. Compliance approach — как подрядчик планирует обеспечить GDPR, Package Travel Directive, AML/KYC и другие требования;
  5. Quality assurance approach — testing strategy, code review process, security audit cadence;
  6. Knowledge transfer plan — как происходит передача знаний на каждой фазе;
  7. Reference clients — 2-3 reference projects сопоставимой сложности с возможностью контакта;
  8. Команда — резюме и кейсы — для всех senior+ ролей.

13.3. Формат​

  • Документ на русском или английском языке (на выбор подрядчика);
  • Структура: title page, executive summary (1 страница), детальные разделы по 13.1 и 13.2;
  • Бюджет в виде таблицы с возможностью per-phase, per-role, per-component breakdown;
  • Готовность к defense презентации перед заказчиком (1.5-2 часа video conference).

14. Заказчик ожидает в коммерческом предложении честность​

  • Никаких заглушек в plan. Если подрядчик считает, что часть scope требует уточнения — явно говорит об этом.
  • Никаких «сделаем за полгода в 5 человек». Это нереалистично для зрелой платформы такого уровня. Заказчик не доверится таким оценкам.
  • Никаких vendor lock-in проприетарных решений. Принцип открытых стандартов — обязательный (раздел 4.4).
  • Никаких MVP с долгом. Принцип развития, не деградации — обязательный (раздел 4.3).
  • Никакого подражания Stuba/HomeToGo в каноничной архитектуре. Правило 00000 — высший приоритет (раздел 4.1).
  • Реалистичная оценка длительности. Продакшн-капабельная зрелая платформа — это 30-36+ месяцев, не 6-12.
  • Прозрачные риски. Все идентифицированные риски — на столе, с mitigation.

15. Срок ответа на ТЗ​

Заказчик ожидает коммерческое предложение в течение 6 недель с момента получения подрядчиком этого ТЗ и связанной документации. В течение этих 6 недель подрядчик имеет право:

  • задавать уточняющие вопросы (отвечает заказчик в течение 3 рабочих дней);
  • запрашивать дополнительные документы;
  • проводить sessions с архитектором заказчика (по запросу);
  • проводить proof of concept на отдельных компонентах (за свой счёт, опционально).

После получения коммерческого предложения заказчик в течение 3-4 недель проводит:

  • внутреннее техническое ревью;
  • defense презентация подрядчика;
  • референс-проверка;
  • финансовое обсуждение;
  • юридическое оформление контракта (NDA → Master Services Agreement → Statement of Work на фазу 1).

Целевой срок начала работ: в течение 2 месяцев после получения коммерческих предложений от 2-3 финалистов.

16. Конкурс​

Это ТЗ направляется 3-5 подрядным организациям одновременно. Заказчик выбирает одну на основе совокупной оценки:

  • архитектурное понимание (40%);
  • состав команды и опыт (25%);
  • бюджет (20%);
  • сроки (10%);
  • модель сотрудничества (5%).

Победитель получает Phase 1 contract. Контракт на Phase 2 выдаётся по результатам Phase 1 (без обязательства; заказчик имеет право сменить подрядчика).

17. Ограничения и условия​

17.1. NDA​

Все материалы (это ТЗ + связанная документация в vitiana-api-platform) предоставлены под Non-Disclosure Agreement. Подрядчик обязан:

  • не передавать документацию третьим лицам без явного разрешения заказчика;
  • не использовать архитектурные решения и подходы для других проектов в течение 24 месяцев;
  • сообщать о всех вовлечённых субподрядчиках и получить разрешение на их участие.

17.2. Working with home-to-go-api​

Существующий код-проект home-to-go-api имеет собственного владельца (заказчика). Подрядчик:

  • получает read access для context;
  • НЕ редактирует home-to-go-api без явного разрешения заказчика для каждого изменения;
  • координирует все изменения через существующий процесс заказчика (home-to-go-api имеет свой CLAUDE.md и Свод законов ИИ).

17.3. Соответствие правилам разработки документации​

Заказчик использует систему документации Docusaurus + Decap CMS с DocMap MCP. Подрядчик:

  • следует тем же стандартам документации, что зафиксированы в cms-docs;
  • не редактирует документы напрямую, а через MCP-инструменты или formal pull request workflow;
  • обновляет документацию в рамках той же задачи, что и код (правило VII в Своде законов ИИ).

17.4. Open-source contributions​

Подрядчик имеет право вносить generic improvements в open-source проекты, используемые в платформе (PostgreSQL, Kafka, Kubernetes operators, etc.) без согласования с заказчиком. Specific компоненты платформы Vitiana — частная собственность заказчика.

18. Контактная информация для заказчика​

Контактные данные подрядчик получает в момент начала переговоров. Главные роли на стороне заказчика:

  • Architect / Project Owner — главный контакт по техническим и архитектурным вопросам;
  • Business Owner — главный контакт по бизнес-решениям, бюджету, фазам;
  • Legal Counsel — для NDA, Master Services Agreement, Statement of Work;
  • Finance — для оплаты milestones и invoices.

19. Приложения​

Все приложения — документы из vitiana-api-platform/ репозитория. Совокупно — более 90 документов. Подрядчик получает доступ ко всему репозиторию после подписания NDA.

19.1. Минимальный набор для оценки scope​

Для качественной оценки scope подрядчик обязан изучить в указанном порядке:

  1. overview/index.md — главная архитектурная ось;
  2. overview/platform-vision-and-manifest.md — манифест переосмысления;
  3. overview/architectural-anchor-and-business-model.md — якорь и бизнес-модель;
  4. Все 5 архитектурных правил-законов (раздел 4 этого ТЗ): Закон 00000 + Современные лучшие практики + Эластичное масштабирование + Развитие без деградации + Тезисное обоснование;
  5. Все 6 осей архитектуры: canonical-domain-spine, layers, platform-as-product, data-and-intelligence-spine, operational-spine, relation-to-implementation-baseline;
  6. overview/architectural-axes-and-cross-links.md — граф пересечений 6 осей с расширением под Фазы 4–6;
  7. operations/scaling-and-packaging-roadmap.md — дорожная карта инфраструктуры;
  8. Все документы reference/ (31 документ) — каноничные доменные модели + платформа как продукт + платформа данных + safety/compliance/security;
  9. Все 9 документов operations/ — особенно Фаза 6: runbooks-incident-playbooks, sla-and-on-call-model, disaster-recovery-and-capacity;
  10. development/roadmap.md — путь развития платформы (6 stages зрелости);
  11. development/team-and-staffing-plan.md — план команды по 7 стадиям;
  12. development/documentation-governance.md — каноничный процесс работы с документами;
  13. development/main-findings.md — главные выводы и проблемные зоны;
  14. 3 open proposals для решения на стадии 1: proposal-stack-roadmap-by-product-tier, proposal-stack-detailed-discussion-russian, proposal-openapi-first-polyglot-codegen;
  15. development/initial-contract-package.md, development/implementation-ready-breakdown.md — первый пакет контрактов и release units.

19.2. Документы home-to-go-api для контекста реализации​

После подписания NDA — read access к репозиторию home-to-go-api. Главные документы:

  1. PLATFORM.md — общая архитектурная карта проекта;
  2. HOTEL_DATABASE.md, GEO_DATABASE.md, USR_ARCHITECTURE.md, EVENTS_THEMES_DB.md — текущие схемы БД;
  3. HOTEL_LOADER.md, HOTEL_SYNC.md, CONTENT_PIPELINE.md — текущие pipelines;
  4. api-module-stuba/docs/CONTRACT.md, STUBA_ARCHITECTURE.md, STUBA_API_REFERENCE.md — Stuba module контракты.

Каноничный мост current → target — в overview/relation-to-implementation-baseline.md (с явной картой 8 каноничных tech debts).

20. Что НЕ входит в это ТЗ​

Для ясности границ:

20.1. Не входит в scope подрядчика​

  • Маркетинг и продажи партнёров — заказчик ведёт самостоятельно;
  • Юридическое оформление контрактов с поставщиками и партнёрами — на стороне заказчика;
  • Дизайн брендинга vitrip.store — на стороне заказчика (подрядчик реализует на готовом дизайне);
  • Контент для каталога (описания отелей дополнительные к тому, что приходит от поставщиков) — на стороне заказчика;
  • Контракты с поставщиками — заказчик ведёт переговоры с поставщиками и подписывает контракты;
  • PSP контракт — заказчик подписывает с выбранным PSP;
  • Регистрация compliance (GDPR DPO registration, insolvency protection contract, etc.) — на стороне заказчика.

20.2. Не покрыто этим ТЗ (отдельные scope при необходимости)​

  • Mobile приложения для конечных клиентов (только webview vitrip.store на старте);
  • Voice interfaces или conversational AI;
  • Blockchain или Web3 компоненты;
  • Прямая интеграция с GDS (Sabre, Amadeus, Galileo) для авиа — рассматривается на фазе 4 как опциональное расширение;
  • Customer support tooling beyond basic ticketing — может быть отдельным проектом.

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

Обязательно к изучению (по приоритетам).

Высший приоритет — фундамент​

Высокий приоритет — все 6 осей​

Высокий приоритет — каноничные домены (для backend архитектуры)​

Высокий приоритет — safety/compliance/security​

Высокий приоритет — operations Phase 6​

Средний приоритет — детализация доменов​

Средний приоритет — платформенные домены​

Средний приоритет — operations baseline​

Средний приоритет — реализация и контракты​

Средний приоритет — async и sync контракты​

Высокий приоритет — Open proposals (для решения на стадии 1)​

Высокий приоритет — Документы развития​

Низкий приоритет — прочее (фоновое чтение)​

Обзорные для бизнес-стороны​