Implementation Technology Baseline — Рекомендуемый технологический фундамент реализации

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

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

Этот документ фиксирует не окончательный “выбор стека навсегда”, а рекомендуемый implementation baseline для промышленной реализации vitiana-api-platform.

Его задача — определить:

• какие технологические решения лучше всего соответствуют уже собранной архитектуре платформы;
• где нужен жёсткий технологический выбор, а где допустимы controlled alternatives;
• как стек должен обслуживать доменные и execution contours, а не подменять их;
• какие решения сейчас выглядят промышленно оправданными для ingestion, domain core, persistence, scaling and deployment.

Опорные документы

• Архитектурная основа платформы vitrip.store
• Development Roadmap — Путь развития платформы от архитектурного baseline к промышленной эксплуатации
• Business Services — Сервисная декомпозиция платформы
• Ingestion Layer — Приём, нормализация, маппинг и governance
• Database Schema — Каноническая модель хранения платформы
• Storage Layer — Модель хранения и жизненный цикл данных
• API Contracts — Surface Contracts и правила внешнего взаимодействия
• Eventing And Queue Baseline — Событийная шина, очереди и асинхронная дисциплина платформы
• Deployment And Operating Model — Развёртывание и эксплуатационная модель
• Release Engineering And Migrations — Релизы, совместимость и эволюция схем
• Observability Tooling Baseline — Технологический baseline наблюдаемости, трассировки и операционной диагностики

Главный Принцип

Технологический стек должен вытекать из разных operational realities платформы:

• supplier intake and transformation;
• canonical and transactional truth;
• offer, quote and booking execution;
• partner and client-facing surfaces;
• observability, release safety and recovery.

Из этого следует:

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

Что Этот Документ Не Должен Делать

Этот документ не должен:

• притворяться, что implementation уже начат и все choices необратимы;
• превращать ранний technology preference в догму;
• подменять architecture decisions прямым списком модных инструментов;
• скрывать, какие решения являются strongly recommended, а какие merely acceptable alternatives.

Рекомендуемый Application Baseline

1. Ingestion Pipeline: Rust

Для supplier intake, heavy normalization, matching-preparation, replay-heavy processing и memory-sensitive throughput задач Rust выглядит наиболее сильным кандидатом.

Почему это оправдано:

• высокая производительность при работе с большими потоками данных;
• строгая memory discipline;
• хорошая предсказуемость под sustained load;
• удобство для long-running ingestion workers and transformation pipelines;
• снижение infra-cost при больших объёмах intake and processing.

Где Rust Особенно Уместен

• batch ingestion;
• streaming or queue-driven processing;
• parsing supplier formats;
• expensive normalization steps;
• replay tooling;
• anomaly pre-classification.

Где Не Нужно Насильно Тащить Rust

• internal admin/BFF convenience code;
• быстро меняющиеся orchestration-oriented operator tools;
• тонкие surface composition layers без heavy data processing.

Domain Core And API Baseline

2. Domain Core And Core APIs: Go

Для core services платформы Go выглядит наиболее сильным baseline choice.

Почему:

• хороший баланс между reliability, simplicity and concurrency;
• предсказуемое поведение под production load;
• сильный fit для networked services, API surfaces, booking/quote orchestration and integration-heavy domains;
• хороший operating profile для containerized distributed systems;
• высокий шанс не превратить platform core в language-complexity tax.

Где Go Особенно Уместен

• offer and commercial services;
• booking service;
• partner-facing APIs;
• internal operational APIs;
• tenant, metering and control services;
• orchestrating service-to-service flows.

Python: Где Допустим, А Где Нет

Python не должен быть default choice для high-load transactional core.

Но он допустим как controlled secondary language:

• analytics and reporting jobs;
• data-science or experimentation contours;
• internal tooling;
• thin BFF or custom adaptation layers, если они не становятся performance-critical core path;
• operator-support utilities and controlled automation.

Жёсткое Ограничение

Python не должен становиться языком для:

• booking truth;
• quote fixation;
• settlement-relevant critical path;
• heavy fan-out partner API workloads;
• latency-sensitive core execution contours.

Persistence Baseline

1. Canonical And Transactional Source Of Truth: PostgreSQL

PostgreSQL остаётся самым разумным baseline choice для:

• canonical entities;
• bookings;
• quotes, если они audit-significant;
• settlement-relevant traces;
• partner clearing state;
• tenant configuration;
• governance and review cases.

Почему:

• ACID semantics;
• mature relational model;
• strong indexing and schema evolution support;
• predictable transaction behavior;
• good fit for financially and operationally critical truth.

2. Operational Cache And Fast Volatile State: Redis Or KeyDB

Подходит для:

• search/session-like volatile data;
• short-lived quote-associated operational helpers;
• cache layers;
• lock-like coordination where justified;
• hot derived views.

Но этот слой не должен становиться source of truth for:

• money;
• booking truth;
• clearing balances;
• settlement traces;
• audit-significant lifecycle state.

3. Search And Content Retrieval Layer: OpenSearch Or Elasticsearch

Для rich discovery, full-text content search, filter-heavy retrieval and geo/search combinations специализированный search engine оправдан.

Почему:

• SQL alone плохо подходит для сложного full-text and faceted search at scale;
• search read model платформы отличается от canonical relational truth;
• surface-facing search workloads требуют отдельной оптимизации.

Важная Оговорка

Search engine должен мыслиться как projection/read layer, а не canonical truth.

Scaling Baseline

Horizontal Scaling — Основной Путь

Для этой платформы горизонтальное масштабирование должно быть baseline strategy.

Особенно это касается:

• search and partner API surfaces;
• ingestion workers;
• quote/revalidation bursts;
• async processing;
• tenant-uneven traffic patterns.

Strongly Recommended Elements

• containerized services;
• independent scaling of critical contours;
• read replicas where read/write asymmetry is real;
• partitioning/sharding only when justified by operational scale, not prematurely;
• queue-backed decoupling for heavy downstream work.

Вертикальное Масштабирование

Остаётся legitimate supporting tactic для:

• primary databases;
• expensive search nodes;
• specialized heavy stateful components.

Но не должно быть главной long-term strategy для всей платформы.

Deployment And Infrastructure Baseline

Kubernetes — Strongly Recommended, But Not A Dogma

Для зрелого production-capable этапа Kubernetes выглядит наиболее естественным baseline choice.

Почему:

• хорошо поддерживает horizontal scaling;
• даёт controlled rollout and isolation model;
• сочетается с multi-service execution contours;
• хорошо работает с observability and release discipline.

Но Важно

Kubernetes не должен считаться обязательным на самой ранней стадии любой ценой.

Если на более раннем этапе controlled production contour проще поднять на managed containers or a simpler runtime without breaking release discipline, это допустимо.

Правильная формула такая:

Kubernetes — предпочтительный target baseline, но не религиозный порог входа в реализацию.

Infrastructure As Code

Terraform or an equivalent IaC approach strongly recommended.

Причины:

• repeatable environments;
• disaster recovery readiness;
• regional expansion readiness;
• partner-dedicated or dedicated environment scenarios;
• lower operational ambiguity.

API Gateway Baseline

API gateway layer действительно нужен.

Он должен покрывать:

• authentication and credential routing;
• rate limiting;
• surface routing;
• environment separation;
• observability hooks;
• request policy enforcement.

Traefik or Kong выглядят разумными кандидатами.

Но gateway не должен становиться местом, где случайно живёт tenant policy, commercial rules or business truth.

Чего В Этом Мнении Не Хватает

Предложенный стек в целом сильный, но сам по себе он ещё не гарантирует industrial fitness.

Не менее критично зафиксировать:

• eventing and queue baseline;
• contract serialization strategy;
• observability stack baseline;
• release gating tooling;
• data replay tooling;
• backup and restore strategy for stateful layers.

То есть хороший стек — это только часть production viability.

Итоговая Рекомендация

На текущем этапе наиболее сильный implementation baseline для платформы выглядит так:

• Rust for ingestion-heavy and replay-heavy processing;
• Go for platform core and critical APIs;
• Python only in controlled secondary contours;
• PostgreSQL as canonical and transactional truth;
• Redis or KeyDB for fast volatile state and cache;
• OpenSearch or Elasticsearch for rich search projections;
• containerized horizontally scalable runtime as the default trajectory;
• Kubernetes as preferred mature target runtime;
• Terraform or equivalent IaC as strong recommendation;
• API gateway as controlled policy edge, but not as business-logic core.

Отдельно для полноты industrial baseline теперь также нужны:

• Eventing And Queue Baseline — Событийная шина, очереди и асинхронная дисциплина платформы
• Observability Tooling Baseline — Технологический baseline наблюдаемости, трассировки и операционной диагностики

Что Должно Быть Сделано Дальше

После фиксации этого baseline нужно:

• синхронизировать deployment, roadmap, overview и main-findings;
• использовать отдельно зафиксированные eventing and observability baselines как next implementation layer;
• не превращать этот документ в преждевременный “approved final stack”, пока не появится implementation-ready breakdown.

Расширение технологического baseline под Фазы 4–6 (27.04.2026)

После Фаз 4–6 опубликованы новые домены и операционные документы, требующие технологических решений, которых не было в исходной версии 1.0 (24.04.2026). Эта секция расширяет baseline новыми доменами и явно оставляет открытые развилки для решения на стадии 1 implementation baseline.

Документ остаётся на версии 1.0, но рассматривается как incomplete baseline до закрытия открытых развилок ниже.

Новые технологические домены, требующие baseline

Платёжный домен (см. payment-domain.md)

Технологические компоненты:

• PSP integration — Stripe / Adyen / Mollie / multi-PSP adapter;
• 3D Secure 2.0 / SCA — handled by PSP;
• PCI DSS compliance — через PSP-only handling (SAQ A);
• Idempotency — application-layer idempotency keys + database constraint;
• Saga для multi-component payments (Tour Builder) — orchestrator или choreography pattern.

Открытые развилки — см. ниже.

Поисковая инфраструктура (см. search-and-discovery.md)

Технологические компоненты:

• Search engine — для facets, ranking, full-text, geo-search;
• Index pipeline — synchronization канонической модели → search projections;
• Ranking framework — pluggable ranking policies per tenant.

Платформа данных и трекинг событий (см. data-platform-and-events-tracking.md)

Технологические компоненты:

• Event bus — для domain events (transactional);
• Event store — append-only persistent storage;
• Stream processing — для real-time enrichment (если нужно);
• DWH — для analytical queries;
• ETL/ELT pipeline — events → DWH;
• Schema registry — для event schema evolution.

Платформа машинного обучения (см. ml-platform.md)

Технологические компоненты:

• Feature store — для feature reuse и serving consistency;
• Model registry — versioning models;
• Model serving — online inference;
• Model monitoring — drift detection, performance metrics;
• Training pipeline — automated retraining.

Платформа A/B-тестирования (см. ab-testing-platform.md)

Технологические компоненты:

• Feature flag service — Unleash / LaunchDarkly / Flagsmith / собственный;
• Experiment assignment — sticky bucketing per actor;
• Exposure tracking — events stream;
• Statistical analysis — power calc, p-value, confidence intervals;
• Integration с analytics (см. analytics-and-bi.md).

Уведомления (см. notification-and-communication.md)

Технологические компоненты:

• Multichannel delivery — email / SMS / push / in-app / webhook;
• Email provider — SendGrid / Mailgun / Postmark / Amazon SES;
• SMS provider — Twilio / Vonage / locale-specific (UkrSMS, OrangeSMS);
• Push — Firebase Cloud Messaging (FCM) для mobile (когда mobile появится);
• Template engine — для multilingual templates;
• Consent management — coordinated с GDPR.

Медиа и контент (см. media-and-content.md)

Технологические компоненты:

• Object storage — для original assets;
• CDN + image transforms — для responsive delivery;
• Image optimization service — Cloudflare Images / imgix / Cloudinary / собственное на основе imagemagick / sharp;
• Video (если будет) — encoding pipeline + adaptive streaming.

Аналитика и BI (см. analytics-and-bi.md)

Технологические компоненты:

• DWH (см. data platform);
• BI dashboarding — Metabase / Apache Superset / Looker / собственное;
• Partner-facing dashboards — embeddable BI или собственные dashboards;
• k-anonymization — automated в DWH layer перед exports.

Новые операционные домены, требующие baseline

Runbooks / Incident management (см. runbooks-incident-playbooks.md)

Технологические компоненты:

• Incident management platform — PagerDuty / Opsgenie / Squadcast / Grafana OnCall;
• Status page — Statuspage.io / Atlassian Statuspage / собственное;
• ChatOps — Slack / Microsoft Teams интеграция с runbooks.

SLA monitoring (см. sla-and-on-call-model.md)

Технологические компоненты:

• SLI metrics collection — Prometheus + Grafana baseline;
• SLO calculation — Pyrra / Sloth / собственное на основе Prometheus;
• SLA reporting — dashboards для tenants;
• Service credit calculation — automated в billing pipeline.

Disaster Recovery (см. disaster-recovery-and-capacity.md)

Технологические компоненты:

• Backup orchestration — Velero (Kubernetes) / WAL-G (PostgreSQL) / cloud provider managed;
• Restore tooling — DR playbook automation;
• Capacity monitoring — Prometheus + Grafana + custom forecasts;
• Chaos engineering (фаза 4+) — Chaos Mesh / Chaos Monkey / Gremlin / собственное.

Новые security / compliance домены

Security architecture (см. security-architecture.md)

Технологические компоненты:

• Secrets management — HashiCorp Vault / AWS Secrets Manager / OVHcloud Vault;
• SIEM — Datadog Security / Wazuh / Splunk / Elastic Security;
• Vulnerability scanning — Snyk / Dependabot / Trivy / Grype;
• WAF — Cloudflare / OVHcloud / ModSecurity;
• mTLS / service mesh (фаза 3+) — Istio / Linkerd / Consul Connect;
• Container security — distroless images, Trivy scanning, signed images через Cosign.

Compliance (см. compliance-and-legal.md)

Технологические компоненты:

• Consent management platform (CMP) — Cookiebot / OneTrust / собственное;
• Data Subject Request (DSR) handling — собственный API + integrations с DWH;
• Audit log retention — отдельный immutable storage tier;
• DPA management — contract repository (DocuSign / собственное).

Каноничные привязки технологий к фазам

Привязка добавлений к фазам infrastructure (см. scaling-and-packaging-roadmap.md):

Технология	Фаза 1 (bootstrap)	Фаза 2 (service isolation)	Фаза 3 (workload-specific)	Фаза 4 (multi-region)
PSP	1 PSP (Stripe рекомендуется)	+ multi-PSP option	full multi-PSP	regional PSPs
Search engine	PostgreSQL FTS	+ Meilisearch для polished search	Elasticsearch / Meilisearch dedicated	multi-region search index
Event bus	PostgreSQL listen/notify или Redis streams	+ dedicated Redis Streams / Kafka	Kafka cluster или managed	multi-region Kafka
DWH	PostgreSQL replica или ClickHouse single-node	+ ClickHouse cluster	dedicated ClickHouse cluster или BigQuery	multi-region DWH
Feature store	application-level	+ Feast или собственное	dedicated Feature Store service	multi-region
Model serving	embedded (PyTorch/TF inference inline)	dedicated inference services	+ GPU pools	multi-region
A/B platform	feature flags simple (PostgreSQL-backed)	+ Unleash или собственное	full A/B platform	multi-region
Email	Mailgun или SendGrid	+ multiple providers с failover	dedicated MTAs если volume justifies	regional providers
SMS	Twilio	+ locale-specific providers	full multi-provider	regional
Push	FCM	+ APNs если iOS	full multi-platform	multi-region
Object storage	OVHcloud Object Storage	+ cross-AZ replication	+ cross-region replication	full multi-region
Image CDN	Cloudflare Images или imgix	+ multi-CDN	+ dedicated transforms service	multi-region
Incident management	PagerDuty или Grafana OnCall	+ status page	+ ChatOps integration	multi-region runbooks
SLI/SLO	Prometheus + Grafana	+ Pyrra или Sloth	full SLA reporting	multi-region
Backup	OVH managed + WAL-G	+ Velero для K8s	+ cross-region replication	multi-region
Secrets management	SOPS или managed simple	+ HashiCorp Vault	full Vault deployment	multi-region Vault
SIEM	Grafana Loki + Prometheus alerts	+ Wazuh или managed	full Datadog Security или Splunk	multi-region SIEM
WAF	Cloudflare basic	+ ModSecurity или managed WAF	+ custom rules	multi-region
Service mesh	none (direct service-to-service)	+ Istio или Linkerd базовый	full service mesh с mTLS	multi-region
Vulnerability scanning	Dependabot + GitHub Security	+ Snyk или Trivy	+ automated penetration testing	continuous

Открытые развилки baseline (требуют решения на стадии 1)

Развилка 1. PSP selection

Вариант A. Stripe — best-in-class, EU subsidiary, broad payment methods, expensive (1.5%+ + per-transaction fees). Вариант B. Adyen — enterprise-grade, NL-based (EU-native), broad coverage, complex onboarding. Вариант C. Mollie — EU-only, simpler, lower cost, narrower feature set. Вариант D. Multi-PSP adapter с фазы 1 — flexibility, но дополнительная сложность.

Влияет на: payment-domain implementation, PCI DSS scope, settlement timing, GDPR data flows.

Trade-off: Stripe — fastest to implement, dependency на one provider. Multi-PSP с нулевого дня — flexibility, но overhead.

Рекомендация: начать с Stripe для bootstrap (фаза 1), abstraction layer для future multi-PSP (фаза 3+).

Развилка 2. Search engine

Вариант A. PostgreSQL native FTS — simplest, no additional infra, ограниченные возможности (no fuzzy search out-of-box, weaker faceting). Вариант B. Meilisearch — open-source, fast, simple, instant search experience. Вариант C. Typesense — open-source, similar to Meilisearch. Вариант D. Elasticsearch / OpenSearch — full-featured, complex ops, cost.

Trade-off: PostgreSQL FTS достаточно для бутстрапа но требует replacement позже. Meilisearch — good balance simplicity + features. Elasticsearch — full power но overkill для bootstrap.

Рекомендация: PostgreSQL FTS на фазе 1 (минимизация infrastructure), Meilisearch на фазе 2 (когда search becomes product feature), миграция на Elasticsearch на фазе 4+ при необходимости.

Развилка 3. Event bus / Event store

Вариант A. PostgreSQL LISTEN/NOTIFY — simplest, ограничения (delivery guarantees, scale). Вариант B. Redis Streams — simple, durable, well-suited для bootstrap. Вариант C. Apache Kafka — production-grade, complex ops, expensive. Вариант D. NATS Jetstream — middle ground, simpler than Kafka. Вариант E. Managed (Confluent Cloud, AWS MSK) — operational simplicity, cost.

Trade-off: PostgreSQL — fragile at scale. Redis Streams — good для бутстрапа. Kafka — full power но operational tax.

Рекомендация: Redis Streams на фазе 1, NATS Jetstream или Kafka на фазе 3.

Развилка 4. DWH technology

Вариант A. PostgreSQL columnar (cstore_fdw, cstore) — extends PostgreSQL, simpler. Вариант B. ClickHouse — open-source, fast, complex ops. Вариант C. BigQuery — managed, expensive at scale, vendor lock-in. Вариант D. Snowflake — similar to BigQuery. Вариант E. DuckDB — embedded analytics, great для simple cases.

Рекомендация: DuckDB или ClickHouse single-node на фазе 1, ClickHouse cluster на фазе 3, decision о managed vs self-hosted на фазе 4.

Развилка 5. Container orchestration

Вариант A. Kubernetes (managed — OVHcloud Managed Kubernetes, Rancher) — industry standard, complex. Вариант B. Nomad — simpler than Kubernetes. Вариант C. Docker Swarm — simplest, limited. Вариант D. Managed containers (OVHcloud Cloud Containers без полного K8s) — для простоты.

Рекомендация: Managed Kubernetes (OVHcloud) с фазы 1 — самый стандартный, экосистема инструментов.

Развилка 6. Secrets management

Вариант A. HashiCorp Vault self-hosted — full feature set, ops cost. Вариант B. HCP Vault — managed. Вариант C. AWS Secrets Manager — managed, vendor lock-in. Вариант D. OVHcloud Vault (если existence) — managed, EU-resident. Вариант E. SOPS + Git — для bootstrap.

Рекомендация: SOPS на фазе 0–1 (bootstrap), HashiCorp Vault на фазе 2.

Развилка 7. Mobile strategy (если выбрано)

Вариант A. Native iOS/Android — best UX, dual codebase cost. Вариант B. React Native — single codebase, near-native. Вариант C. Flutter — single codebase, full custom UI. Вариант D. PWA — web-only, лимиты native features.

Рекомендация: PWA на фазе 3 для B2C surface, native consideration на фазе 5+.

Развилка 8. Frontend framework

Вариант A. Next.js (React) — широчайшая экосистема, SSR/SSG. Вариант B. SvelteKit — simpler, performant. Вариант C. Solid Start — performance-focused, smaller community. Вариант D. Remix — full-stack, focus on web standards.

Каждый surface может использовать разное:

• agency surface — Next.js (rich UI, complex workflows);
• B2C — Next.js или SvelteKit (SSR для SEO, performance);
• partner UI — Next.js (consistency).

Рекомендация: Next.js (React) для всех surfaces — максимизация talent pool и ecosystem leverage.

Развилка 9. Backend language(s)

Вариант A. TypeScript / Node.js — широчайший pool, weak performance. Вариант B. Go — fast, simple, growing pool. Вариант C. Rust — fastest, smallest pool, learning curve. Вариант D. Java/Kotlin — enterprise standard, JVM costs. Вариант E. Python — для ML только.

Рекомендация: TypeScript / Node.js для основных services (agency, partner API, frontend BFF), Go для performance-critical (search, ingestion, payment), Python для ML platform только. Rust — для специальных случаев (например, high-throughput proxy).

Развилка 10. SDK languages для partners

Вариант A. TypeScript only — простейший. Вариант B. TS + Python + PHP + Go (top 4 партнёрских языков) — coverage. Вариант C. Auto-generated SDKs из OpenAPI — coverage maximum, less polished.

Рекомендация: TypeScript SDK как primary (manual, polished), auto-generated SDKs для остальных (Python, PHP, Ruby, Go) на фазе 3+.

Каноничный итог

Этот документ — incomplete baseline до закрытия 10 открытых развилок выше. Решения принимаются на стадии 1 implementation baseline в каноничном порядке:

1. Container orchestration (фаза 0–1 — нужен сразу) → managed Kubernetes;
2. Backend language baseline (фаза 1) → TypeScript primary + Go для performance-critical;
3. Frontend framework (фаза 1) → Next.js;
4. PSP (фаза 1–2) → Stripe (с abstraction layer);
5. Search engine (фаза 1) → PostgreSQL FTS, переход на Meilisearch фаза 2;
6. Event bus (фаза 1) → Redis Streams;
7. Secrets management (фаза 1) → SOPS, переход на Vault фаза 2;
8. DWH (фаза 2) → DuckDB или ClickHouse single-node;
9. Mobile strategy (фаза 3) → PWA initial;
10. SDK strategy (фаза 3) → TypeScript primary + auto-generated.

Эти решения формируют implementation-ready technology baseline для перехода в stage 1.

Уточнение под Ось 6 (28.04.2026) — связь с home-to-go-api текущим стеком

Этот документ описывает рекомендуемый технологический baseline для имплементации Vitiana. Платформа строится поверх работающего ядра home-to-go-api, не green-field. Эта секция фиксирует обязательные связи с текущим технологическим стеком и path конвергенции.

Главный мост — relation-to-implementation-baseline.md

Полная карта current vs target — в overview/relation-to-implementation-baseline.md.

Текущий стек home-to-go-api

Компонент	Текущее	Целевое (рекомендация этого документа)	Path конвергенции
Backend язык	PHP	TypeScript primary + Go (см. proposal-stack-roadmap)	Strangler Fig: новые services в TS/Go, PHP остаётся для legacy paths
Frontend B2C (vitrip.store)	Preact + HTM	Next.js 15 App Router (Node.js)	Next.js для новых rich pages; existing Preact для базовых до миграции
Frontend admin	(нет в полном виде)	Vite SPA + React + TanStack Router	разработка с нуля под Tour Builder
Database	PostgreSQL 18.1 (apivitianadb)	PostgreSQL 18 (тот же)	без миграции БД, расширение схемы
Search	прямые SQL queries	PostgreSQL FTS (Phase 1) → Meilisearch (Phase 2) → Elasticsearch (Phase 4)	новый search service
Event bus	(нет)	Redis Streams (Phase 1) → NATS Jetstream (Phase 3)	разработка с нуля
DWH	(нет; используется managed PostgreSQL)	DuckDB / ClickHouse single-node (Phase 2) → ClickHouse cluster (Phase 3)	разработка с нуля
Cache	(нет dedicated; используется PHP session/Apache)	Redis 7	разработка с нуля
Object storage	(используется существующий с фотографиями)	OVHcloud Object Storage (S3-compatible)	возможно тот же; уточнить
Container orchestration	(нет полноценного)	Managed Kubernetes (OVHcloud)	разработка с нуля
Secrets management	(basic)	SOPS (Phase 0–1) → HashiCorp Vault (Phase 2)	разработка с нуля
CI/CD	manual / partial	GitHub Actions или GitLab CI	разработка с нуля
Observability	(нет полного stack)	Prometheus + Grafana + Loki + Tempo	разработка с нуля

Production реальность home-to-go-api (на 27.04.2026)

• БД: apivitianadb PostgreSQL 18.1, хост vitianaapipg.psql.tools:10167;
• production endpoint: https://api.vitrip.store/stuba (Stuba adapter, не Partner API Surface);
• vitrip.store как первая B2C поверхность (Preact + HTM, PHP backend);
• 127 304 отелей загружены, 4.6M фотографий;
• 182 страны синхронизированы;
• Stuba module production-ready 2026-04-15.

Принципы миграции (из relation-to-implementation-baseline.md)

1. Strangler Fig pattern — новые сервисы вокруг existing, постепенная замена legacy paths;
2. Canonical model first — каждое расширение начинается с canonical schema, потом code;
3. Tenant isolation от первого commit — multi-tenant aware с самого начала;
4. No hardcoded supplier logic — adapter pattern;
5. Security by design — review каждого нового code path до production;
6. Compliance by design — privacy review для PII handling.

Что home-to-go-api даёт стартовый капитал для технологического baseline

1. PostgreSQL 18.1 уже работает — сетка БД, managed backups, performance tuning сделаны → не пересобираем;
2. Stuba integration в production — pattern для второго supplier;
3. vitrip.store как B2C testing ground — реальный traffic для оценки performance;
4. OVHcloud baseline уже выбран — managed PostgreSQL, infrastructure path подтверждён;
5. 127K hotels + 4.6M фото — real data для load testing нового стека.

Связь с открытыми развилками этого документа

В секции «Открытые развилки baseline» (часть «Расширение технологического baseline под Фазы 4–6» этого документа) перечислены 10 открытых вопросов. Текущая реализация home-to-go-api влияет на decision per развилку:

Развилка	Влияние home-to-go-api	Рекомендация stage 1
PSP selection	(не реализован)	Stripe для bootstrap (см. proposal)
Search engine	прямые SQL queries	PostgreSQL FTS Phase 1, миграция позже
Event bus	(нет)	Redis Streams Phase 1
DWH	(нет)	DuckDB / ClickHouse single-node Phase 2
Container orchestration	(нет полноценного K8s)	Managed K8s OVHcloud Phase 1
Secrets management	(basic)	SOPS bootstrap, Vault Phase 2
Mobile strategy	(нет)	PWA на Phase 3
Frontend framework	Preact + HTM	Next.js + Vite (см. proposal-stack-roadmap)
Backend language	PHP	TS + Go (см. proposal-stack-roadmap)
SDK languages	(нет partner SDK)	TypeScript primary + auto-generated

Связь с proposal-stack-roadmap-by-product-tier

development/proposal-stack-roadmap-by-product-tier.md — расширенная stack roadmap по продуктовым слоям и фазам, открытый proposal для решения на стадии 1. Канонические рекомендации:

• B2C (vitrip.store): Next.js 15 + Server Components;
• Admin / Tour Builder: Vite + React SPA (отдельно);
• Partner UI: Next.js (separate app);
• Backend services: Go primary, Rust для critical paths (Phase 3+);
• ML: Python (Phase 4+).

При несоответствии этого документа и proposal — proposal recent more детальный для polyglot стратегии.

Связь с proposal-openapi-first-polyglot-codegen

development/proposal-openapi-first-polyglot-codegen.md — open proposal по OpenAPI-first стратегии для polyglot:

• single source of truth: openapi.yaml per surface;
• code generation: oapi-codegen (Go), OpenAPI Generator (Rust/TS/Python/PHP);
• documentation: Redoc (public) + Swagger UI (sandbox).

home-to-go-api на 27.04 не имеет OpenAPI спецификаций — это первая задача стадии 1 при формализации Partner API Surface.

Каноничный итог уточнения

Этот документ описывает target technology baseline. Path implementation:

• Карта current vs target → overview/relation-to-implementation-baseline.md;
• 8 каноничных tech debts → reference там же;
• Расширение под Фазы 4–6 (новые домены) → секция «Расширение технологического baseline» в этом документе;
• Stack по слоям и фазам → proposal-stack-roadmap-by-product-tier.md;
• OpenAPI-first для polyglot → proposal-openapi-first-polyglot-codegen.md;
• Strangler Fig pattern для миграции → reference в relation-to-implementation-baseline.

При имплементации использовать этот документ как target stack, relation-to-implementation-baseline.md как карту current state, два proposals как открытые вопросы для решения на стадии 1.

Уточнение выполнено через no-destruction.