Предложение (proposal) — дорожная карта стека по продуктовым слоям и фазам зрелости

Версия: 1.0 Дата: 27.04.2026 Статус: Открытый вопрос (на обсуждение, не утверждённое решение)

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

Этот документ — proposal (предложение, не утверждённое решение) о технологическом стеке платформы Vitiana, разложенном по продуктовым слоям (B2C frontend, agency/admin/Tour Builder, partner UI, backend services, ML) и фазам зрелости (1–6 development roadmap).

Документ дополняет proposal-openapi-first-polyglot-codegen.md (который касается code generation и contracts) — focused специфично на language / runtime / framework choice per layer per phase.

Документ не утверждает архитектурное решение. Решение принимается на стадии 1 implementation baseline с участием главного архитектора и future Tech Lead.

Документ ссылается на существующие принципы и технологические baseline без их правки. Существующий implementation-technology-baseline.md рекомендует TypeScript + Go как backend baseline; этот proposal расширяет картину явным split на frontend / BFF / backend / performance-critical / ML слои.

Контекст развилки

Что уже зафиксировано в платформе

• implementation-technology-baseline.md — рекомендует TypeScript primary + Go для performance-critical; явно incomplete до закрытия 10 открытых развилок;
• clients.md — фиксирует 6 каноничных surfaces (Internal Operational, Agency Working, Partner Machine, Partner UI/SDK, B2C, White-Label) с разными требованиями;
• api-as-product.md — фиксирует tier model (Free / Starter / Professional / Enterprise);
• tour-builder-operational-model.md — Tour Builder как core с saga / drift detection / multi-component composition;
• search-and-discovery.md — search как domain с ranking policy;
• payment-domain.md — payment с zero-touch к card data, PSP integration.

Что НЕ зафиксировано

• Frontend rendering strategy — SSR vs SSG vs SPA per surface;
• Deep linking / SEO требования для B2C — не привязаны к конкретному framework;
• Backend language split — где Node.js, где Go, где Rust, где Python;
• Admin / Tour Builder UI architecture — separate SPA или часть Next.js monorepo;
• Talent pipeline considerations для каждого языка в первой волне (UA / CZ / PL + EU broader).

Главный архитектурный тезис

Платформа Vitiana — это три разных продукта под одной архитектурой, каждый со своими требованиями:

Продукт	Главное требование	Производное от
B2C frontend (vitrip.store)	SEO + deep linking + Core Web Vitals	поисковый трафик — главный канал travel acquisition
Admin / Agency / Tour Builder	Rich interactivity + real-time pricing + drag-and-drop	сложный stateful workflow, авторизованный доступ
Backend platform	Performance + memory safety + concurrency	multi-tenant, high-volume, security-critical

Эти три продукта имеют разные оптимальные стеки. Попытка использовать единый стек для всех приводит к компромиссам, ограничивающим каждый из продуктов.

Тезисное обоснование

Тезис 1. Frontend и backend — разные слои, разные оптимальные стеки.

Альтернативы:

• (а) Single language full-stack — TypeScript / Node.js везде или Rust везде;
• (б) Frontend = TypeScript, Backend = arbitrary — фиксируем frontend, backend по необходимости;
• (в) Per-layer optimal — Next.js (Node.js) для frontend, Go primary для backend, Rust для critical paths.

Trade-off: вариант (а) даёт code reuse (shared types через TS), но компromises performance (Node.js не подходит для Tour Builder pricing) или developer velocity (Rust для frontend — мучительно); вариант (б) логичен, но не определяет backend; вариант (в) — каноничный pattern Stripe / Linear / Vercel: Next.js / Node.js BFF + Go/Rust backend services. Это масштабируется на каждом слое независимо.

Тезис 2. Next.js — оптимальный выбор для B2C фронта с SEO + deep linking.

Альтернативы:

• (а) Next.js (Node.js SSR) — Server Components для SEO, server actions для booking flow, streaming;
• (б) Pure SPA (Vite + React) — best DX, нет SSR, плохо для SEO;
• (в) SvelteKit — performant, smaller community;
• (г) Solid Start / Astro — performance-focused, narrower ecosystem;
• (д) Server-rendered Go templates — fast, нет developer velocity современного frontend.

Trade-off: вариант (а) — broadest ecosystem, deep linking через URL state работает natively, SEO works для каждого варианта filter / tab / offer; вариант (б) — нет SEO benefit (критично для travel); вариант (в) хороший но меньший pool; вариант (г) — рискованно для большой команды; вариант (д) — нет.

Booking.com, Airbnb, Skyscanner, Expedia — все на SSR React-стеках (Next.js или собственные). Это де-факто стандарт travel B2C.

Тезис 3. Admin / Tour Builder UI — SPA, не SSR.

Альтернативы:

• (а) Same Next.js codebase с /admin/* route group;
• (б) Separate Vite + React SPA в отдельном repository / package;
• (в) Embedded в Next.js но client-side rendered ('use client' everywhere).

Trade-off: вариант (а) — shared codebase + design system, но Server Components здесь не выигрывают (UI меняется на каждый клик, не на каждую route navigation); вариант (б) — separation of concerns, faster HMR, optimized bundle для interactive UI, но дополнительный repository; вариант (в) — теряет benefits Next.js не получая benefits SPA.

Tour Builder с drag-and-drop, real-time pricing recalculation, saga state visualization — это classic SPA territory. Next.js Server Components для admin = over-engineering. Vite + TanStack Router (SPA) — natural fit.

Recommendation:

• На фазе 1 — single Next.js app с /admin/* (минимизация infrastructure + команды);
• На фазе 3 — выделение Vite SPA для admin когда complexity justifies (Tour Builder становится rich product feature, agency surface растёт).

Тезис 4. Backend — Go primary, Rust для critical paths (отложен).

Альтернативы:

• (а) Pure Node.js / TypeScript backend — same language как frontend, code reuse;
• (б) Go primary + Rust для critical paths с фазы 1;
• (в) Go primary + Rust добавляется по metrics на фазе 3+;
• (г) Pure Rust backend — radical performance.

Trade-off:

• (а) — V8 GC pauses убивают p99 latency для Tour Builder pricing с 50+ supplier pricing concurrent calls; single-threaded model плохо ложится на ingestion с 10+ параллельными supplier'ами; memory safety слабее, чем нужно для payment domain. Это работает для small scale, ломается при росте.
• (б) — over-engineering для bootstrap (4–8 человек). Hiring senior Rust engineer на стадии 1 дорого и медленно (Rust pool в EU/CIS значительно уже Go).
• (в) — оптимальный путь: Go покрывает 95% workloads, Rust добавляется по data (metrics показывают p99 deterioration в Go) и justified hiring (фаза 3 уже стабильная команда).
• (г) — тоже самое что (б), радикальнее.

Recommendation: (в) — Go primary с фазы 1, Rust для critical paths на фазе 3 при появлении data-justifying triggers.

Тезис 5. Python только для ML.

Альтернативы:

• (а) Python везде где удобно (scripts, glue code, ML);
• (б) Python только для ML inference + training;
• (в) No Python, всё через Go / Rust scripts.

Trade-off: вариант (а) приводит к появлению Python services где не нужно; вариант (в) — недопустим (PyTorch / TF / sklearn ecosystem только в Python); вариант (б) — каноничный split: Python isolated в ML platform, остальное (включая utilities / scripts) — Go.

Recommendation: (б) — Python для ML serving (FastAPI + PyTorch / TF) и data science scripts; не для production services вне ML.

Тезис 6. BFF (Backend-for-Frontend) — Node.js logically, не Go.

Альтернативы:

• (а) Frontend → Go services напрямую через REST/gRPC;
• (б) Frontend → Node.js BFF → Go services;
• (в) Frontend → GraphQL gateway → Go services.

Trade-off: вариант (а) — frontend делает 5–10 service calls per screen, latency накапливается, complex aggregation в client; вариант (б) — Next.js Server Actions / Route Handlers это natural BFF, aggregation on server, single roundtrip к client; вариант (в) — GraphQL имеет смысл при multiple frontend teams с разными data needs (фаза 5+), не сейчас.

Recommendation: (б) на фазах 1–4 (Next.js BFF), консидеринг (в) на фазе 5+ при росте frontend teams.

Тезис 7. Полное SSR vs partial — partial через React Server Components.

В Next.js 15 App Router default: Server Components rendered на сервере, Client Components отмечены 'use client'. Это даёт:

• SEO works automatically (HTML отдаётся с server-side data);
• deep linking natively через searchParams (server-side decode → server-side render);
• interactive parts (dropdown, modals) — Client Components с гидратацией;
• payment forms — Server Actions без exposed credentials.

Это современный pattern, не legacy SSR. Согласовано с modern best practices.

Каноничная стек-связка по слоям

Слой 1. Frontend rendering — B2C (vitrip.store)

Аспект	Выбор	Альтернатива
Framework	Next.js 15 App Router	SvelteKit, Remix
Runtime	Node.js LTS	Bun (фаза 5+ при stability)
Rendering	Server Components default + Client Components selective	full SSR / full SSG
Routing	App Router (file-based)	TanStack Router
State (server)	Server Components data fetching	—
State (client)	TanStack Query + Zustand для local	Redux Toolkit, Jotai
Forms	React Hook Form + Zod schemas	Formik
Styling	Tailwind CSS + CSS Modules где нужно	styled-components, Emotion
Component library	Radix UI primitives + custom design system	Shadcn UI baseline
Image optimization	Next.js <Image> + sharp	imgix, Cloudflare Images
Internationalization	next-intl или react-i18next	—
Analytics integration	потребление через единый client (см. data-platform-and-events-tracking)	—
A/B testing client	потребление через единый experiment client (см. ab-testing-platform)	—
Payment UI	Stripe Elements / Adyen Components (PSP-managed iframe)	—

Ключевые требования закрываются:

• SEO: Server Components → server-rendered HTML с данными → search engines видят полный контент;
• Deep linking: URL-as-state через searchParams. Например:

  /hotels?city=prague&checkin=2026-05-01&priceMax=500&tab=reviews&offer=abc123

  Каждый набор параметров → отдельная rendered страница с правильным контентом. Share-able links work.
• Core Web Vitals: streaming, partial hydration, edge rendering для static parts;
• Booking flow: Server Actions для server-side validation + payment intent creation без exposed PSP keys.

Слой 2. BFF — Backend for Frontend

Аспект	Выбор
Runtime	Next.js Server Actions + Route Handlers (тот же Node.js process)
Auth boundary	NextAuth / собственный session management
Service communication	OpenAPI-generated TS clients (см. proposal-openapi-first-polyglot-codegen.md)
Aggregation	Server Components fetching + parallel Promise.all
Caching	Next.js cache() + revalidation
Error envelope	Каноничный error envelope (см. api-contracts.md)

BFF не отдельный сервис на фазах 1–3 — он часть Next.js application. На фазе 5+ при росте teams возможно выделение в separate Node.js gateway или GraphQL.

Слой 3. Admin / Agency / Tour Builder UI

Фаза 1–2 — внутри Next.js monorepo

Аспект	Выбор
Routing	/admin/* route group в Next.js
Rendering	Client Components default (admin не нуждается в SSR)
Shared design system	npm workspace package

Фаза 3+ — separate Vite SPA

Аспект	Выбор
Build tool	Vite
Framework	React 19
Routing	TanStack Router (type-safe, file-based)
State	TanStack Query (server state) + Zustand (UI state)
Real-time	tRPC subscriptions или Server-Sent Events для pricing updates
Drag-and-drop	dnd-kit
Form handling	React Hook Form + Zod
Tour Builder UI primitives	собственная библиотека (composable blocks)
Saga state visualization	XState devtools-inspired UI
Bundle optimization	Vite tree-shaking + manual code splitting

Shared design system между B2C Next.js и admin Vite — через npm workspace package (@vitiana/ui).

Слой 4. Partner UI / SDK

Partner self-service portal

Аспект	Выбор
Framework	Next.js (отдельный subdomain partner.vitiana.com или route group)
Rendering	Mix Server / Client (marketing pages — SSG, dashboard — SPA-like)
Authorization	Capability-based (см. clients.md)
Sandbox UI	Swagger UI или собственное (см. proposal-openapi-first-polyglot-codegen.md)
Documentation	Redoc-rendered (auto-generated from OpenAPI)

Partner SDK

Язык	Tool
TypeScript	hand-crafted SDK + auto-generated types
Python, PHP, Ruby, Go	OpenAPI Generator auto-generated
Java, .NET (фаза 5+)	OpenAPI Generator

Слой 5. Backend services

Слой 5A. Core backend — Go

Каноничные services на Go:

• booking-service — booking lifecycle, state machine;
• payment-service — PaymentIntent flow, refund, chargeback (в фазе 3+ может быть переписан в Rust);
• partner-service — partner lifecycle, certification;
• notification-service — multichannel delivery;
• settlement-service — partner clearing, payouts;
• ingestion-service — supplier intake, normalization (mapping layer to canonical model);
• tenant-service — tenant management;
• media-service — media asset management;
• i18n-service — translations, FX rates;
• metering-service — API usage tracking;
• webhook-delivery-service — outbound webhooks с retry;
• governance-service — review queues, manual decisions.

Stack для Go services:

Аспект	Выбор
Go version	1.23+ (latest stable)
HTTP framework	chi или echo (lightweight)
OpenAPI generation	oapi-codegen (см. proposal-openapi-first-polyglot-codegen.md)
Database access	pgx/v5 (low-level) или sqlc (type-safe codegen)
Migrations	golang-migrate или goose
Validation	go-playground/validator
Logging	slog (stdlib structured)
Tracing	OpenTelemetry SDK
Testing	testify + table-driven tests + testcontainers-go для integration
gRPC (если нужно internal)	grpc-go + protoc-gen-go
Async tasks	own queue consumer + Redis Streams
Concurrency	goroutines + errgroup + context propagation

Слой 5B. Performance-critical / Security-critical — Rust (отложен до фазы 3)

Кандидаты для Rust на фазе 3+:

• pricing-engine — real-time Tour Builder composition pricing с 50+ supplier concurrent;
• search-orchestrator — query planning + parallel supplier search aggregation (Meilisearch / Elasticsearch wrapper);
• saga-coordinator — Tour Builder transaction saga state machine;
• webhook-signature-validator — high-throughput HMAC validation для inbound webhooks;
• rate-limiter-core — high-performance token bucket implementation;
• payment-innermost-layer — для extra security guarantees (опционально — Go может быть достаточно).

Stack для Rust services (когда выбран):

Аспект	Выбор
Rust edition	2024 (latest stable)
HTTP framework	axum
OpenAPI generation	OpenAPI Generator (rust-server template) либо utoipa для Rust-only
Database access	sqlx (async, type-safe)
Migrations	sqlx-cli или внешние (shared с Go services)
Async runtime	tokio
Logging	tracing
Tracing	OpenTelemetry SDK
Testing	built-in + testcontainers-rs
Serialization	serde

Принцип миграции Go → Rust:

Не «переписать весь сервис». Migrate hot paths в Rust как библиотеку, вызываемую через FFI (C ABI) из Go service, либо отдельный Rust service за gRPC interface. Это reduces risk и позволяет gradual transition.

Слой 5C. ML — Python

Аспект	Выбор
Python version	3.12+
Web framework (для inference API)	FastAPI
ML frameworks	PyTorch, scikit-learn, XGBoost (per use case)
Feature store client	Feast Python SDK или собственный
Serving	TorchServe, BentoML, или собственный wrapper
Training pipeline	Apache Airflow или Prefect или Kubeflow
Model registry	MLflow или собственный
Notebook environment	Jupyter (для exploration)
Package management	poetry или uv

Integration с остальной платформой:

• ML services exposed как gRPC или REST endpoints (auto-generated typed clients для Go consumers);
• feature store — отдельная storage layer, доступна из Go services;
• training pipelines — separate orchestration, не coupled с production traffic.

Слой 6. Data layer

Аспект	Выбор	Phase
Primary OLTP	PostgreSQL 18	1
Search	PostgreSQL FTS → Meilisearch (фаза 2) → Elasticsearch (фаза 4+)	1
Cache	Redis 7	1
Event store	Redis Streams → NATS Jetstream (фаза 3)	1
Object storage	OVHcloud Object Storage (S3-compatible)	1
DWH	DuckDB / ClickHouse single-node → ClickHouse cluster (фаза 3) → managed (фаза 5)	2
Time-series (метрики)	Prometheus	1
Logs	Grafana Loki	1
Distributed traces	Tempo / Jaeger	2

Слой 7. Infrastructure

Аспект	Выбор
Cloud	OVHcloud (primary), AWS/GCP — будущая опция для multi-cloud DR
Container orchestration	OVHcloud Managed Kubernetes
Service mesh (фаза 3+)	Istio или Linkerd
API Gateway	Kong, Traefik, или OVHcloud managed
CDN	Cloudflare
WAF	Cloudflare + ModSecurity
Secrets	SOPS (фаза 0–1) → HashiCorp Vault (фаза 2+)
CI/CD	GitHub Actions или GitLab CI
IaC	Terraform
Image registry	Harbor (self-hosted) или OVHcloud managed

Слой 8. Observability

Аспект	Выбор
Metrics	Prometheus + Grafana
Logs	Grafana Loki
Traces	Tempo или Jaeger (OpenTelemetry collector)
Alerting	Grafana Alertmanager или PagerDuty integration
SLI/SLO	Pyrra или Sloth
Status page	Statuspage.io или собственное
Incident management	PagerDuty или Grafana OnCall
SIEM (фаза 4+)	Wazuh, Datadog Security, или Splunk

Дорожная карта стека по фазам

Фаза 1 — Bootstrap (4–8 человек)

Frontend:

• Next.js 15 (всё B2C + admin как route group);
• shared design system как internal package.

Backend:

• Go everywhere — no Rust yet, no Python (за исключением optional ML POC если есть).

Data:

• PostgreSQL 18 (primary);
• Redis (cache + Streams для events);
• PostgreSQL FTS для search;
• DuckDB или PostgreSQL для analytics.

Infrastructure:

• OVHcloud Managed Kubernetes (single cluster);
• Cloudflare CDN + basic WAF;
• SOPS для secrets;
• GitHub Actions CI/CD;
• Prometheus + Grafana + Loki.

Что НЕ в фазе 1:

• Rust services;
• Python services (ML — мок или пропустить);
• separate admin SPA;
• Vault;
• service mesh;
• multi-cloud.

Фаза 2 — Service isolation (8–14 человек)

Frontend:

• Next.js (no change);
• начало shared design system maturity.

Backend:

• Go (no Rust yet);
• начало декомпозиции на отдельные services.

Data:

• • Meilisearch для polished search;
• • ClickHouse single-node для analytics;
• • cross-AZ PostgreSQL replication.

Infrastructure:

• • HashiCorp Vault (миграция с SOPS);
• • Velero для K8s backup;
• multi-AZ deployment.

Что добавляется:

• DR drills (partial restore monthly);
• improved CI/CD с automated rollback;
• distributed tracing (Tempo).

Фаза 3 — Controlled external beta + workload-specific packaging (15–25 человек)

Frontend:

• Выделение Vite SPA для admin / Tour Builder (separate package);
• shared design system как published npm package.

Backend:

• Введение Rust для critical paths — кандидаты:
  • pricing-engine (Tour Builder real-time pricing);
  • search-orchestrator (Meilisearch wrapper для multi-supplier aggregation);
• Go продолжает primary для всех остальных.

Data:

• • Elasticsearch consideration (если Meilisearch не справляется);
• • ClickHouse cluster (если volume justifies);
• secondary region cold standby для Tier 1+2.

Infrastructure:

• • service mesh (Istio или Linkerd) для mTLS;
• • automated capacity forecasting;
• chaos drills (chaos-mesh или собственное).

ML:

• Python ML platform начинается (FastAPI + PyTorch для ranking).

Фаза 4 — Production-capable baseline (25–45 человек)

Frontend:

• Mobile strategy decision (PWA vs native);
• additional Vite SPA для partner self-service (если оправдано отдельностью от B2C Next.js).

Backend:

• Rust расширяется на дополнительные critical paths по metrics;
• Go primary для основной массы.

Data:

• managed DWH consideration (BigQuery / Snowflake) — economic decision;
• multi-region cold standby.

Infrastructure:

• SOC 2 Type 1 readiness (security tooling, audit infrastructure);
• Datadog Security или Wazuh для SIEM;
• bug bounty program private launch.

ML:

• ML team formation (2–3 ML engineers);
• feature store deployment;
• A/B platform full integration.

Фаза 5 — Controlled scale (45–80 человек)

Frontend:

• GraphQL gateway consideration (если 3+ frontend teams с разными data needs);
• mobile native (iOS/Android) если PWA insufficient;
• multi-region edge rendering.

Backend:

• additional Rust services (если needed);
• consider Bun runtime для frontend (если stability подтверждена).

Data:

• multi-region active-active database (CockroachDB / Yugabyte consideration).

Infrastructure:

• SOC 2 Type 2;
• public bug bounty.

Фаза 6 — Multi-region and enterprise (80+ человек)

Frontend:

• regional edge presence;
• white-label SDK с branding customization.

Backend:

• regional service deployment;
• dedicated infrastructure для Enterprise tenants.

Data:

• full multi-region with data residency per tenant;
• regional DWH replicas.

Infrastructure:

• ISO 27001;
• DPO infrastructure (GDPR DPIA full automation).

Связь с уже зафиксированными решениями

Согласование с правилами платформы

• ✅ Правило 00000 — стек platform-first, не диктуется поставщиками;
• ✅ Современные лучшие практики — Stripe (Ruby + Go + Scala), Twilio (Java + Node.js + Go), Vercel/Next.js team (TypeScript + Rust для performance critical); pattern «multi-language с per-layer optimal» подтверждён;
• ✅ Эластичное масштабирование и упаковка по фазам — каждый язык вводится по триггеру фазы, не сразу;
• ✅ Развитие без деградации — Go primary даёт smooth path; Rust добавляется как extension, не replacement;
• ✅ Тезисное обоснование — каждый выбор обоснован с альтернативами.

Согласование с другими документами

• api-as-product.md — partner SDK strategy (TS primary + auto-generated) совместима;
• clients.md — 6 surfaces map на frontend layers (B2C Next.js, Admin Vite SPA, Partner Next.js + SDK);
• multi-tenant-isolation-strength.md — Go services поддерживают tenant isolation на application layer;
• payment-domain.md — Stripe Elements (frontend) + Go payment-service (backend) + (опционально Rust) для payment innermost;
• tour-builder-operational-model.md — saga-coordinator кандидат на Rust в фазе 3.

Talent pipeline (соображения)

Восточная Европа + EU broader

Язык	Talent pool	Median seniority
TypeScript / React / Next.js	Очень широкий	Junior → Senior
Go	Средний, растущий	Mid → Senior
Rust	Узкий, специфичный	Senior only (часто crypto/fintech background)
Python (ML)	Широкий для general, средний для ML	Mid → Senior для general, Senior for ML

Вывод для hiring strategy:

• Фаза 1 — фокус на TS + Go (доступно, broad pool);
• Фаза 3 — first Rust hire — обычно internal upskilling Go senior + 1–2 external Rust senior hires;
• Фаза 4+ — ML hires (Python + ML expertise specific search).

Ключевые решения для Tech Lead

Этот proposal оставляет открытыми решения, которые принимаются на стадии 1 совместно с future Tech Lead:

1. Repository structure — monorepo (Turborepo / Nx) или multi-repo;
2. Package manager — pnpm vs npm vs yarn;
3. Specific Go HTTP framework — chi vs echo vs gin (стилистическое);
4. Database access pattern в Go — pgx low-level vs sqlc vs ORM (вероятно нет);
5. Real-time pricing protocol — WebSocket vs SSE vs polling (для Tour Builder);
6. State management в frontend — TanStack Query primary, но Zustand vs Jotai для local state;
7. Specific design system base — Radix UI vs Headless UI vs собственное from scratch;
8. TS strict mode level — strictest или practical;
9. Test framework для frontend — Vitest vs Jest;
10. Browser testing — Playwright vs Cypress.

Ключевые риски стратегии

Риск 1. Polyglot complexity

При неправильном execution polyglot может стать source of fragmentation. Mitigation:

• shared OpenAPI / AsyncAPI contracts (см. proposal-openapi-first-polyglot-codegen.md);
• caнoничный error envelope across languages;
• shared observability stack;
• automated cross-language integration tests.

Риск 2. Rust hiring blocker

Rust pool узкий, hiring senior может затянуться. Mitigation:

• Rust добавляется только на фазе 3 когда команда стабильна;
• internal upskilling Go senior — viable path;
• start с одного Rust hire, не команды;
• Go fallback для каждого Rust path (если Rust hire fails, не блокирует delivery).

Риск 3. Next.js vendor lock-in (Vercel)

Vercel — primary platform для Next.js, есть deployment lock-in. Mitigation:

• Next.js может deploy на own infrastructure (Docker → Kubernetes);
• никаких Vercel-specific features в production code;
• self-hosted deployment from фаза 1.

Риск 4. Bun / new runtime allure

Bun, Deno, новые runtimes выглядят attractive но не production-ready для нашего scale. Mitigation:

• Node.js LTS как default до фазы 5+;
• evaluation новых runtimes в isolated POCs, не production paths.

Риск 5. Over-engineering на ранних стадиях

Premature Rust adoption, premature service mesh, premature multi-cloud. Mitigation:

• explicit phase gates (см. roadmap выше);
• каждый upgrade требует data-driven justification.

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

Этот proposal предлагает per-product per-phase optimal stack:

Фаза 1 (bootstrap):

• Frontend: Next.js 15 + Node.js (всё, включая admin как route group);
• Backend: Go everywhere;
• Data: PostgreSQL + Redis + PostgreSQL FTS;
• Infrastructure: OVHcloud K8s + Cloudflare + SOPS.

Фаза 3 (controlled external beta):

• Frontend: Next.js B2C + Vite SPA admin/Tour Builder;
• Backend: Go primary + Rust для critical paths;
• Data: + Meilisearch + ClickHouse;
• Infrastructure: + Vault + service mesh.

Фаза 4+:

• Frontend: + mobile strategy;
• Backend: extending Rust footprint by metrics;
• ML: Python platform full;
• Data: managed DWH consideration.

Фаза 6:

• Multi-region everywhere;
• ISO 27001 readiness;
• Enterprise dedicated infrastructure.

Решение не утверждено этим документом — это open proposal, требующий обсуждения с future Tech Lead на стадии 1 implementation baseline.

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

Связанные предложения (proposals)

• Предложение OpenAPI-first для polyglot кодогенерации (proposal-openapi-first-polyglot-codegen.md) — code generation strategy для polyglot стека.

Опорные технологические документы

• Implementation Technology Baseline (implementation-technology-baseline.md) — текущий baseline (incomplete);
• API контракты (api-contracts.md) — surface contracts;
• Дорожная карта инфраструктурного масштабирования (scaling-and-packaging-roadmap.md) — фазы инфраструктуры;
• Развёртывание и эксплуатационная модель (deployment.md) — execution contours.

Доменные документы

• Клиентские поверхности (clients.md) — 6 surfaces, capability matrix, truth visibility;
• Программный интерфейс как продукт (api-as-product.md) — partner experience;
• Tour Builder домен (tour-builder-domain.md) — Tour Builder как core;
• Операционная модель Tour Builder (tour-builder-operational-model.md) — saga, drift, composition;
• Поиск и обнаружение (search-and-discovery.md) — search engine choice;
• Платёжный домен (payment-domain.md) — PSP integration;
• Архитектура безопасности (security-architecture.md) — supply chain security;
• Платформа машинного обучения (ml-platform.md) — Python stack rationale;
• Сила тенантной изоляции (multi-tenant-isolation-strength.md).

Документы развития

• Дорожная карта развития платформы (roadmap.md) — фазы зрелости;
• План команды и штатной структуры (team-and-staffing-plan.md) — hiring по фазам;
• Управление документацией (documentation-governance.md) — review процесс для proposals.

Архитектурные правила

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