Brief Technical Specification (Abstract Layer)

Version: 1.0 Date: 28.04.2026 Status: Ready for discussion

Purpose of the Document

This document is an abstracted summary of the platform's full technical specification, intended for preliminary evaluation by external contracting organizations, architects, consultants, and expert groups at the pre-NDA stage.

The document conveys the essence, goals, architectural scale, and key requirements.

1. What Is Being Built

A global, flexible, modular top-tier B2B platform for the travel industry. The platform aggregates travel-service data from multiple external suppliers and sells access to that data to different sales channels: travel agencies, corporate travel services, white-label partners, and its own B2C storefront.

Main product components:

• Programmatic interface as a product (B2B API marketplace) — the main commercial product; a paid programmatic interface for integrating external partners with a tariff model and a mature service model;
• Composer and API for complex multi-component tours — a modular closed API for assembling itineraries from accommodation, transfers, activities, services, insurance, and other components; available to paying partners as full functionality, not a stripped-down copy;
• Own B2C storefront(s) — a public sales channel oriented to organic search traffic and good page-speed metrics;
• Workspace for travel agencies — a complete sales and support working system, not just a "hotel-search website".

2. Main Architectural Intent

The platform is designed from its own goals and is not adapted to the structures of specific suppliers. Any supplier must be connectable and disconnectable without reworking the core. The canonical model is primary; supplier data is normalized into it through adapters. This requires strict discipline: prohibition of "convenient" captive integrations with a single supplier, and prohibition of mixing supplier and platform truth in a single table or a single API object.

The architecture is based on modern patterns of top-tier platforms in fintech, communications, search, content, and infrastructure; legacy patterns of the travel industry are not copied. Reinterpretation of others' practices is allowed, but not their repetition.

3. Six Top-Layer Architectural Axes

The platform is decomposed along six interrelated axes:

Axis 1. Canonical domain axis. Seven groups of canonical entities with explicit lifecycles:

• master entities (stable identity of objects and products, organizations, policies, governance decisions);
• supplier-derived entities (a trace of what came from outside; never replaces the canonical entities);
• operational offer entities (offer, availability snapshot, price snapshot, commercial fixation, revalidation result, search session);
• transactional entities (booking, booking item, lifecycle event, payment intent, refund, change request);
• compositional entities (tour draft, composition item, alternative variant, tour commercial proposal, proposal version, materialized artifact);
• governance and review entities (review case, mapping and merge decisions, anomaly, field provenance, source-priority rule);
• subject, tenant, and access entities (tenant, workspace, role assignment, granted permission, programmatic client, credentials, actor working context).

Axis 2. Interaction surfaces. Six formal contractual surfaces (internal operational / agency working / partner programmatic interface / B2C storefront / service-to-service / closed tour composer) and six product client surfaces (internal tools / agency cabinet / partner machine integration / partner UI and SDK / B2C / embeddable widgets with the partner's own brand). Each surface is an independent contract with its own evolution pace, set of permissible fields, commercial-amount visibility policy, and authentication. The principle of "one programmatic interface for all" is rejected as false.

Axis 3. Platform as a product. Four pricing tiers with explicit differences in service guarantees, isolation, analytical products, and volume envelopes. Dynamic pricing of platform services depending on the volume of search queries, commercial fixations, bookings, supplier load, query complexity, machine-learning inference, notification delivery, and storage volume. A complete partner lifecycle from registration in the test environment to certification and production onboarding. Self-service partner controls: dashboard, key rotation, notification subscription management, consumption telemetry, audit log download.

Axis 4. Data and intelligence axis. Six classes of events with different guarantees of delivery, ordering, and retention: domain events (the source of truth for downstream logic), analytical events (behavioral traces), saga events (transactional coordination of multi-component operations), audit and security events (immutable journaling with tamper detection), operational events (disaster recovery, capacity, incidents, SLA violations), regulatory-compliance events (data subject requests, consents, breach notifications). The data warehouse as a separate storage class, separated from the operational and transactional layers. A machine-learning platform with a feature store, model registry, prediction serving system, and model monitoring. An A/B experimentation framework as a product capability, not one-off experiments in code. Analytics and BI as an independent product for partners with protection against deanonymization of small groups.

Axis 5. Operational axis. Elastic infrastructure with auto-scaling from day zero. Isolation of execution contours. Guaranteed capacity for premium partners. Backpressure discipline on asynchronous queues. Graceful degradation under overload. Managed services are primary in early phases, open standards everywhere (no provider lock-in). Disaster-recovery plan with explicit recovery target metrics. Regular recovery drills. Observability as a product — metrics, traces, logs, dashboards for the team and for partners. Formal incident management with runbooks for canonical incident classes, on-call rotation, the role of incident commander, and a culture of blameless post-mortems. Release discipline with feature flags, gradual rollout, contract testing, and an explicit compatibility policy.

Axis 6. Relation to implementation. Every decision takes into account the current state of the platform, captures technical debt, and defines a convergence path to the canonical target architecture.

4. Seven Main Development Principles

1. The platform is supreme over suppliers. The canonical model is derived from the platform's goals. Any field appears because the domain requires it, not because it is returned that way by a specific supplier. Any supplier can be detached without reworking the core.
2. Modern top-tier best practices. Prohibited: a monolithic database with shared state across all domains, synchronous chains through several services on the critical path, "god services", CRUD APIs over domain entities, distributed monolith, manual reconciliation as a regular path, captive integrations with a single supplier, payment provider, or cloud provider.
3. Growth, not degradation. No stubs, no temporary solutions without a migration plan, no hardcoded bindings. Each implementation phase is an extension, not a migration. Each decision is designed as mature and implemented in phases. Prohibited: "one model now, we'll split it later", "one surface now, we'll add nuances later".
4. Open standards, no provider lock-in. Technology choices follow open standards wherever applicable. Migration between cloud providers must be a local refactoring, not a rewrite.
5. Thesis-based justification of decisions. Every non-trivial architectural decision contains a goal, supporting theses, rejected alternatives with justification, accepted trade-offs, and a relation to other decisions. Phrases like "this is better", "everyone does it this way", "it's obvious" are prohibited.
6. Domain-Driven Design. Explicit bounded contexts, ubiquitous language within each context, aggregates as the unit of consistency, domain events as the means of communication between contexts, hexagonal architecture (ports and adapters) for isolating the core from external dependencies.
7. Idempotency, replay safety, observability. All critical mutating operations are idempotent (with client-supplied idempotency keys). All asynchronous consumers are idempotent and replay-safe. Schema discipline for all events and commands. Every inter-service interaction produces a trace and metrics.

5. Target Quality Characteristics

5.1. Service Level

Four tiers of service-level agreements (from a free trial up to enterprise). Ten canonical quality metrics:

• surface availability;
• search latency (95th percentile);
• commercial-fixation latency (95th percentile);
• booking-fixation latency (95th percentile);
• notification-delivery latency (95th percentile);
• share of bookings in an undefined external state (when the supplier does not respond or responds incorrectly — a critical operational metric, target value below 1% for the premium tier);
• share of successful payments under nominal load;
• share of successful recovery drills;
• mean time to recovery for critical incidents;
• time to first response by support for critical tickets.

In case of agreement violations — automatic compensation in the form of credits to the partner balance with different depths (from minor to severe). Per-tier error budgets with alerts on burn rate. When more than half of the monthly budget is spent, a release requires additional approval.

5.2. Security

• STRIDE-based threat model (spoofing / tampering / repudiation / information disclosure / denial of service / elevation of privilege) for each new capability;
• Identity and access management: a role-based approach combined with an attribute-based one; fine granularity; a canonical capability-set resolver;
• Authentication levels: single-factor (for basic users), two-factor (for all privileged and payment operations), step-up (for especially sensitive operations);
• Short-lived access tokens, refresh tokens with rotation, service-account keys with automatic rotation;
• Mutual TLS for service-to-service (from the medium-scale phase);
• Encryption at rest (with support for customer-managed keys for enterprise tenants);
• Encryption in transit (the latest stable TLS version is mandatory at external endpoints);
• Secret management via a specialized solution with automatic rotation;
• DDoS and web-attack protection at the perimeter level;
• Supply-chain security: a software bill of materials for each release, vulnerability scanning, signed commits and containers, trusted base images;
• Container security: a read-only root filesystem, non-root user, dropping unnecessary capabilities, seccomp profiles;
• Comprehensive audit logging in immutable storage (Write Once Read Many) with tamper detection via hash chains; long retention period;
• External penetration testing (annually from the medium-scale phase, twice a year from the maturity phase);
• Bug-bounty program (private, then public);
• Vulnerability remediation SLAs: critical — 24 hours, high — 7 days, medium — 30 days, low — 90 days;
• SOC 2 (Type 1, then Type 2) and ISO 27001 compliance audits at the corresponding maturity phases.

5.3. Personal Data Protection

• GDPR-by-design approach in every component;
• Catalog of fields with explicit legal basis for processing (consent / contract / legal obligation / vital interests / public task / legitimate interests);
• Personal-data minimization at capture;
• Anonymization at the analytical-event level (hashed identifiers, generalized geolocation);
• Retention discipline with automated deletion;
• Auditing of every access to personal data;
• Cross-border data transfer mechanisms (standard contractual clauses for non-EEA destinations);
• Canonical data-subject rights API: access, rectification, erasure, restriction of processing, objection, portability; the target response time is significantly lower than the legal maximum;
• Privacy-impact assessment for high-risk processes (automated decision-making with legal effects, large-scale tracking);
• Privacy review of every new capability before release to production;
• Breach notification: 72 hours to notify the supervisory authority, without undue delay to affected data subjects in case of high risk;
• A consent-management platform for cookies and tracking (with granular consent by category and an easy way to withdraw consent);
• Data-processing agreements with all external processors before any data flow;
• A publicly available list of sub-processors;
• A data protection officer when regulatory thresholds are reached.

5.4. Regulatory Compliance by Maturity Phase

• Baseline personal-data protection requirements (GDPR + ePrivacy + local adaptations) — from day one;
• Payment-services regulation and card-data security standards — at the first payment acceptance;
• Travel margin VAT regulation and package-travel directives — when conducting commercial activity with EU customers;
• Local laws of first-wave jurisdictions: data-localization requirements for specific jurisdictions, separate tax regimes;
• Anti-money-laundering and know-your-customer requirements — when financial operations grow in volume;
• SOC 2 Type 1 certification at the production-ready phase, Type 2 at the scaling phase, ISO 27001 at the maturity phase.

5.5. Reliability

• Idempotency of all critical mutating operations;
• Replay safety of all asynchronous consumers;
• Backpressure discipline on asynchronous queues;
• Circuit breakers at critical external-call points;
• Graceful degradation under overload: per-tenant rate limiting, disabling of non-critical capabilities via feature flags, slowdown of batch tasks, read-only mode for heavy search queries;
• Multi-region active-active configuration for read paths in the maturity phase;
• Multi-region active-passive configuration for write paths in the maturity phase, with an explicit consistency model.

Four canonical recovery tiers with target metrics:

• transactional truth and audit — strictest metrics (recovery within an hour, loss no greater than five minutes, long retention period, monthly partial drills and quarterly full drills);
• operational truth and projections — less strict;
• analytical truth and model features — relaxed metrics;
• archival data — extended recovery time is acceptable.

Eight canonical incident classes with detailed response procedures, post-mortems, and improvement loops. Protection against on-call burnout: a limited number of on-call weeks per engineer over a defined interval depending on the phase.

5.6. Maintainability and Performance

• Clear bounded contexts in code;
• Hexagonal architecture with explicit ports and adapters;
• Code review for every merge;
• Automated tests: unit tests with at least 80% coverage of the domain core, integration, contract, end-to-end, and load tests;
• Up-to-date documentation for each service;
• Architecture decision records for non-trivial choices;
• New developer onboarding time — no more than two weeks before the first productive merge;
• Cache hit ratio for read paths on the B2C storefront over 85%;
• Database query latency at the 95th percentile below 50 milliseconds for canonical reads;
• Database query latency at the 95th percentile below 200 milliseconds for transactional writes;
• Typical search query latency at the 95th percentile below 500 milliseconds;
• Gateway overhead below 10 milliseconds (95th percentile).

6. Target Volumes

• Support for tens of thousands of search queries per day in the early phase;
• Support for millions of search queries per day in the maturity phase;
• Support for tens of millions of search queries per day in the scaling phase;
• The architecture must scale horizontally without rewrites at every order of magnitude of growth;
• Connection of several suppliers in early phases, dozens of suppliers with different integration formats in mature phases without significant core refactoring.

7. Implementation Approach

The platform is developed using a phase-based model with metric and domain triggers for transitions between phases. Not a calendar plan, but movement driven by triggers.

No MVP stubs, no captive integrations for a single supplier, no temporary solutions without a migration plan. Each decision is designed as mature.

Four Phases of Infrastructure Maturity

• Start. Managed services for database, object storage, container orchestration in a single region. Basic observability. A minimum viable set of canonical domains: multi-tenancy migration, booking state machine, payment domain, baseline regulatory compliance, baseline security, transactional-truth recovery.
• Service isolation. Replication across availability zones for critical data. Automated daily test recovery. Managed secrets platform with automatic rotation. Event bus for domain events. Advanced search engine. Observability stack with computation of service-quality metrics. Formal release engineering with tier-aware canary rollout. Multi-tier on-call structure. Stabilized partner programmatic interface with sandbox and certification. First enterprise-relevant ML applications. Experimentation framework in baseline implementation. SIEM as a separate stack.
• Specialized workload packaging. Dedicated compute capacity for the critical core. Dedicated GPU pools for machine learning. Standby region with cold reserve for critical data. Cross-region replication of object storage. Cluster data warehouse for analytics. Production-grade machine-learning platform with a feature store, model registry, prediction-serving system, and model monitoring. Mature A/B experimentation framework. Partner analytical product for premium tiers with deanonymization protection. 24/7 on-call coverage across time zones. Service mesh with full mutual TLS. External penetration testing. Private bug-bounty program. Enterprise service tier. Possible migration of critical paths to a memory-safe language when there are measurable reasons.
• Multi-region configuration and dedicated infrastructure. Multi-region active-active or active-passive configuration with automatic failover. Distributed database with multi-master writes. Deployment across multiple availability zones for critical operations. Global DNS-based routing with health checks. Dedicated infrastructure for enterprise tenants. Regional data localization for regulated jurisdictions. Multi-region observability with federation. Multi-region SIEM. Formal SOC 2 Type 2 audits and progress toward ISO 27001. Enterprise-grade disaster recovery. Marketplace of additional capabilities. Anti-money-laundering and know-your-customer through specialized providers. Expansion into new geographies. A data protection officer when regulatory thresholds are reached. Continuous penetration testing. Public bug-bounty program.

8. End-to-End Scenarios (For Architecture Validation)

The contractor must take into account that the architecture must support the following end-to-end scenarios:

1. Searching for and booking a single accommodation through the B2C storefront with application of the commercial policy, capture of conversion events, and post-sale communication.
2. Searching for and booking a single accommodation through the partner programmatic interface with tenant-dependent visibility, dynamic pricing, and notification-delivery confirmation.
3. Building a complex multi-component tour with component-compatibility validation, handling of discrepancies between the build-time state and the current supplier state, and generation of a materialized artifact (PDF, share link).
4. Conversion of a tour commercial proposal into a multi-booking transaction with coordination of confirmations from multiple suppliers, handling of partial failures, and atomic fixation.
5. Cancellation and modification of a booking with supplier coordination, refund calculation, settlement adjustment, and partner-balance update.
6. Supplier failure in the middle of a booking with alternative search, customer communication, and financial adjustment.
7. Currency conversion in a cross-jurisdictional transaction (customer in one country, object in another, payment in a third currency).
8. GDPR data-subject request (full export plus full deletion while maintaining the audit log).
9. Full partner lifecycle — from registration in the test environment to certification and production onboarding.
10. Partner billing cycle with consumption aggregation, pricing, threshold-overshoot detection, invoice generation, and payment processing.
11. A/B experiment on the B2C storefront with user cohort assignment, impression tracking, statistical-significance computation, and decision-making.
12. Deployment of a machine-learning model for search ranking with simultaneous exposure of multiple versions and automatic rollback on degradation.
13. Disaster-recovery drill with restoration from a geographically redundant backup in an alternative region, data-integrity verification, and computation of service-level violations.

9. What Is Definitely NOT Within the Contractor's Scope

• Marketing and sales of partners;
• Legal contracting with suppliers and partners;
• B2C storefront brand design (the contractor implements on a finished design);
• Catalog content beyond what comes from suppliers;
• Direct contracts with suppliers;
• Direct contract with a payment provider;
• Registration of compliance obligations with regulators.

Separate scopes if needed (not covered by this brief):

• Native mobile applications for end customers in early phases (only an adaptive web storefront);
• Voice interfaces or conversational AI;
• Blockchain components;
• Direct integration with global distribution systems for air in early phases;
• Mature customer support beyond basic ticketing.

10. Project Complexity Summary

A platform of this level is:

• a global, flexible, modular top-tier B2B platform, not a single website and not a single integration;
• more than 40 canonical components with varying complexity (from medium to very high);
• more than a dozen end-to-end scenarios, each spanning several architectural layers;
• four phases of infrastructure maturity with metric and domain transition triggers;
• regulatory coverage across several jurisdictions, data localization, and tax regimes;
• a mature operational model with multi-dimensional recovery, incident classes, multi-tier on-call rotations, explicit service-quality metrics, and automatic compensations on their violation;
• architectural discipline that does not allow "temporary solutions" — every decision is designed as mature and implemented in phases as an extension, not as a migration.

11. What the Customer Expects

• Understanding of the approximate scope of work;
• A ROM estimate with a price range;
• An approximate timeline to the MVP version;
• An approximate technology stack;
• A response to this request within 5 business days to the e-mail of our representative, for consideration of NDA signing.

This document is a summary for preliminary evaluation. After NDA signing, the contractor receives access to all platform documents with clearly stated goals.