Стисле технічне завдання (абстрактний шар)

Версія: 1.0 Дата: 28.04.2026 Статус: Готовий до обговорення

Призначення документа

Цей документ — абстрагована витяжка повного технічного завдання платформи для попереднього оцінювання зовнішніми підрядними організаціями, архітекторами, консультантами, експертними групами на етапі до підписання NDA.

Документ передає суть, цілі, архітектурний масштаб і ключові вимоги.

1. Що розробляється

Глобальна гнучка модульна B2B-платформа верхнього рівня для туристичної індустрії. Платформа об'єднує дані туристичних послуг від множини зовнішніх постачальників і продає доступ до цих даних різним каналам продажу: туристичним агенціям, корпоративним службам подорожей, white-label-партнерам, власній B2C-вітрині.

Головні продуктові компоненти:

• Програмний інтерфейс як продукт (B2B API marketplace) — основний комерційний продукт; платний програмний інтерфейс для інтеграції зовнішніх партнерів з тарифною моделлю та розвиненою моделлю обслуговування;
• Інструмент і API складних багатокомпонентних турів — модульний закритий API для збирання маршрутів зі розміщення, переїздів, активностей, послуг, страхування та інших компонентів; доступний платним партнерам як повноцінна функціональність, не спрощена копія;
• Власна B2C-вітрина(-и) — публічний канал продажу з орієнтацією на органічний пошуковий трафік і добрі показники сторінкової швидкості;
• Робоче місце для туристичних агенцій — повноцінна робоча система продажу та супроводу, не просто «сайт пошуку готелів».

2. Головний архітектурний намір

Платформа проектується від власних цілей, не підлаштовується під структури конкретних постачальників. Будь-який постачальник має підключатися й відключатися без переробки ядра. Канонічна модель — первинна; дані постачальників нормалізуються в неї через адаптери. Це вимагає суворої дисципліни: заборона на «зручні» захоплювальні інтеграції з одним постачальником, на змішування постачальницької та платформенної істини в одній таблиці чи одному API-об'єкті.

Архітектура спирається на сучасні патерни верхньорівневих платформ фінтеху, комунікацій, пошуку, контенту, інфраструктури; legacy-підходи туристичної індустрії не копіюються. Допускається переосмислення чужих практик, не їх повторення.

3. Шість архітектурних осей верхнього шару

Платформа декомпонована вздовж шести взаємопов'язаних осей:

Вісь 1. Канонічна доменна вісь. Сім груп канонічних сутностей з явними життєвими циклами:

• мастер-сутності (стабільна ідентичність об'єктів і продуктів, організації, політики, управлінські рішення);
• сутності, похідні від постачальників (траса того, що прийшло ззовні; ніколи не підміняє канонічні);
• операційні сутності пропозиції (пропозиція, знімок доступності, знімок ціни, комерційна фіксація, результат повторної перевірки, пошукова сесія);
• транзакційні сутності (бронювання, елемент бронювання, подія життєвого циклу, намір платежу, повернення, запит на зміну);
• композиційні сутності (чернетка туру, елемент композиції, альтернативний варіант, комерційна пропозиція туру, версія пропозиції, матеріалізований артефакт);
• сутності керування й перевірки (кейс рев'ю, рішення про мапінг і злиття, аномалія, походження поля, правило пріоритету джерела);
• сутності суб'єктів, тенантів і доступу (тенант, робочий простір, призначення ролі, видане право, програмний клієнт, облікові дані, робочий контекст актора).

Вісь 2. Поверхні взаємодії. Шість формальних контрактних поверхонь (внутрішня операційна / агентська робоча / партнерський програмний інтерфейс / B2C-вітрина / сервіс-до-сервісу / закритий конструктор турів) і шість продуктових клієнтських поверхонь (внутрішні інструменти / агентський кабінет / партнерська машинна інтеграція / партнерський UI і SDK / B2C / вбудовувані віджети з власним брендом). Кожна поверхня — самостійний контракт зі своїм темпом еволюції, набором допустимих полів, політикою видимості комерційних сум і автентифікацією. Принцип «один програмний інтерфейс для всіх» відкинуто як хибний.

Вісь 3. Платформа як продукт. Чотири тарифних рівні з явними відмінностями за гарантіями обслуговування, ізоляцією, аналітичними продуктами, об'ємними конвертами. Динамічна тарифікація платформенних послуг, що залежить від обсягу пошукових запитів, комерційних фіксацій, бронювань, навантаження на постачальників, складності запитів, інференсу машинного навчання, доставки сповіщень, обсягу зберігання. Повноцінний життєвий цикл партнера від реєстрації в середовищі тестування до сертифікації та бойового підключення. Самостійні засоби керування партнером: dashboard, ротація ключів, керування підписками на сповіщення, телеметрія споживання, завантаження журналів аудиту.

Вісь 4. Вісь даних та інтелекту. Шість класів подій з різними гарантіями доставки, упорядкованості та строків зберігання: доменні події (джерело істини downstream-логіки), аналітичні події (поведінкові сліди), події саг (транзакційна координація багатокомпонентних операцій), події аудиту та безпеки (незмінне журналювання з виявленням підробки), операційні події (відновлення після аварій, ємність, інциденти, порушення SLA), події відповідності вимогам регуляторів (запити суб'єктів даних, згоди, повідомлення про порушення). Сховище даних як окремий клас сховища, відокремлене від операційного й транзакційного шарів. Платформа машинного навчання з вітриною ознак, реєстром моделей, системою видачі прогнозів і моніторингом моделей. Каркас A/B-експериментів як продуктова можливість, не разові експерименти в коді. Аналітика та BI як самостійний продукт для партнерів із захистом від деанонімізації малих груп.

Вісь 5. Операційна вісь. Еластична інфраструктура з авто-масштабуванням з нульового дня. Ізоляція контурів виконання. Гарантована потужність для преміум-партнерів. Дисципліна зворотного тиску на асинхронних чергах. Граціозна деградація при перевантаженні. Керовані сервіси первинні на ранніх фазах, відкриті стандарти всюди (без замикання на провайдері). План відновлення після катастрофічних збоїв з явними цільовими показниками відновлення. Регулярні навчання з відновлення. Спостережуваність як продукт — метрики, трасування, журнали, дашборди для команди й для партнерів. Формальний інцидент-менеджмент з runbook для канонічних класів інцидентів, розподілом чергувань, роллю командувача інцидентом, культурою безвинних постмортемів. Релізна дисципліна з feature-флагами, поступовим викочуванням, контрактним тестуванням, явною політикою сумісності.

Вісь 6. Зв'язок із реалізацією. Кожне рішення враховує поточний стан платформи, фіксує технічний борг і визначає шлях конвергенції до канонічної цільової архітектури.

4. Сім головних принципів розробки

1. Платформа є головною щодо постачальників. Канонічна модель — від цілей платформи. Будь-яке поле з'являється тому, що домен цього вимагає, а не тому, що в конкретного постачальника так повертається. Будь-який постачальник можна відключити без переробки ядра.
2. Сучасні найкращі практики верхнього рівня. Заборонено: монолітну базу зі спільним станом між усіма доменами, синхронні ланцюжки через декілька сервісів у критичному шляху, «боги-сервіси», CRUD-API над доменними сутностями, розподілений моноліт, ручну звірку як штатний шлях, захоплювальні інтеграції з одним постачальником, провайдером платежів чи хмарним провайдером.
3. Розвиток, не деградація. Жодних заглушок, тимчасових рішень без плану міграції, hardcode-прив'язок. Кожна фаза реалізації — розширення, не міграція. Кожне рішення проектується як зріле, реалізується за фазами. Заборонено «зараз одна модель, потім розділимо», «зараз один surface, потім додамо нюанси».
4. Відкриті стандарти, без замикання на провайдері. Технологічні вибори — за відкритими стандартами скрізь, де це доречно. Міграція між хмарними провайдерами має бути локальним рефакторингом, не переписуванням.
5. Тезисне обґрунтування рішень. Кожне нетривіальне архітектурне рішення містить мету, тези підтримки, відхилені альтернативи з обґрунтуванням, прийняті компроміси, зв'язок з іншими рішеннями. Заборонено формулювання «так краще», «всі так роблять», «це очевидно».
6. Domain-Driven Design. Явні обмежені контексти, повсюдна мова всередині кожного контексту, агрегати як одиниця узгодженості, доменні події як спосіб комунікації між контекстами, hexagonal architecture (порти й адаптери) для ізоляції ядра від зовнішніх залежностей.
7. Ідемпотентність, безпека повторного відтворення, спостережуваність. Усі критичні мутувальні операції ідемпотентні (з клієнтськими ключами ідемпотентності). Усі асинхронні споживачі ідемпотентні та безпечні для повторного відтворення. Дисципліна схем для всіх подій і команд. Кожна внутрішньосервісна взаємодія породжує трасу й метрики.

5. Цільові якісні характеристики

5.1. Рівень обслуговування

Чотири рівні угод про рівень обслуговування (від безкоштовної оцінки до корпоративного). Десять канонічних метрик якості:

• доступність поверхні;
• затримка пошуку (95-й процентиль);
• затримка комерційної фіксації (95-й процентиль);
• затримка фіксації бронювання (95-й процентиль);
• затримка доставки сповіщень (95-й процентиль);
• частка бронювань у невизначеному зовнішньому стані (коли постачальник не відповідає або відповідає некоректно — критична операційна метрика, цільове значення менш ніж 1% для преміум-рівня);
• частка успішних платежів за штатного навантаження;
• частка успішних навчань з відновлення;
• середній час відновлення для критичних інцидентів;
• час першої відповіді підтримки для критичних звернень.

При порушенні угод — автоматичні компенсації у вигляді кредитів на партнерський баланс із різною глибиною (від незначної до серйозної). Бюджет помилок per рівень з алертами по швидкості витрачання. При витрачанні понад половину місячного бюджету — реліз вимагає додаткового підтвердження.

5.2. Безпека

• Модель загроз за STRIDE (підробка / спотворення / відмова від дії / витік інформації / відмова в обслуговуванні / підвищення привілеїв) для кожної нової можливості;
• Керування ідентичністю та доступом: рольовий підхід у комбінації з атрибутним; тонка гранулярність; канонічний резолвер набору можливостей;
• Рівні автентифікації: однофакторний (для базових користувачів), двофакторний (для всіх привілейованих і платіжних операцій), підвищення фактора (для особливо чутливих операцій);
• Короткоживучі токени доступу, оновлювані токени з ротацією, ключі сервісних облікових записів з автоматичною ротацією;
• Взаємний TLS для сервіс-до-сервісу (з фази середнього масштабу);
• Шифрування при зберіганні (з підтримкою ключів, керованих клієнтом, для корпоративних тенантів);
• Шифрування при передачі (остання стабільна версія TLS обов'язкова на зовнішніх точках);
• Керування секретами через спеціалізоване рішення з автоматичною ротацією;
• Захист від DDoS та веб-атак на рівні периметра;
• Безпека ланцюга постачання: специфікація складу програмного забезпечення для кожного релізу, сканування вразливостей, підпис комітів і контейнерів, довірені базові образи;
• Контейнерна безпека: тільки-для-читання коренева файлова система, не-root користувач, скидання непотрібних capabilities, профілі seccomp;
• Всеохоплююче журналювання аудиту в незмінному сховищі (Write Once Read Many) з виявленням підробки через ланцюги хешів; тривалий строк зберігання;
• Зовнішнє тестування на проникнення (щорічно з фази середнього масштабу, двічі на рік з фази зрілості);
• Програма баг-баунті (приватна, потім публічна);
• SLA на усунення вразливостей: критичні — 24 години, високі — 7 днів, середні — 30 днів, низькі — 90 днів;
• Аудити відповідності SOC 2 (Type 1, потім Type 2) та ISO 27001 на відповідних фазах зрілості.

5.3. Захист персональних даних

• Підхід GDPR-by-design у кожному компоненті;
• Каталог полів з явною правовою підставою обробки (згода / контракт / законний обов'язок / життєві інтереси / суспільне завдання / законні інтереси);
• Мінімізація персональних даних при захопленні;
• Анонімізація на рівні аналітичних подій (хешовані ідентифікатори, узагальнена геолокація);
• Дисципліна строку зберігання з автоматичним видаленням;
• Аудит кожного доступу до персональних даних;
• Механізми транскордонної передачі даних (стандартні договірні положення для не-EEA напрямків);
• Канонічний API прав суб'єкта даних: доступ, виправлення, видалення, обмеження обробки, заперечення, переносимість; цільовий строк відповіді значно нижчий за законний максимум;
• Оцінка впливу на приватність для процесів високого ризику (автоматизоване ухвалення рішень з правовими наслідками, великомасштабне відстеження);
• Огляд приватності кожної нової можливості до випуску в продакшн;
• Повідомлення про порушення: 72 години на повідомлення наглядового органу, без необґрунтованої затримки до постраждалих суб'єктів даних при високому ризику;
• Платформа керування згодами для cookie і трекінгу (з гранулярною згодою за категоріями та простою можливістю відкликання);
• Угоди про обробку даних з усіма зовнішніми обробниками до будь-якого потоку даних;
• Публічно доступний список під-обробників;
• Відповідальний за захист даних при досягненні регуляторних порогів.

5.4. Відповідність регуляторам за фазами зрілості

• Базові вимоги щодо захисту персональних даних (GDPR + ePrivacy + локальні адаптації) — з самого початку;
• Регулювання платіжних послуг та стандарти безпеки карткових даних — при першому прийманні платежу;
• Регулювання туристичного маржинального ПДВ та директиви щодо комплексних турів — при комерційній діяльності з EU клієнтами;
• Локальні закони юрисдикцій першої хвилі: вимоги локалізації даних для окремих юрисдикцій, окремі податкові режими;
• Протидія відмиванню коштів та ідентифікація клієнтів — при зростанні обсягів фінансових операцій;
• Сертифікація SOC 2 Type 1 на фазі production-готовності, Type 2 на фазі масштабування, ISO 27001 на фазі зрілості.

5.5. Надійність

• Ідемпотентність усіх критичних мутувальних операцій;
• Безпека повторного відтворення всіх асинхронних споживачів;
• Дисципліна зворотного тиску на асинхронних чергах;
• Переривачі ланцюга на критичних точках виклику зовнішніх систем;
• Граціозна деградація при перевантаженні: обмеження швидкості per тенант, відключення некритичних можливостей через feature-флаги, уповільнення batch-задач, режим тільки-для-читання для важких пошукових запитів;
• Багаторегіональна активно-активна конфігурація для шляхів читання на фазі зрілості;
• Багаторегіональна активно-пасивна конфігурація для шляхів запису на фазі зрілості з явною моделлю узгодженості.

Чотири канонічних рівні відновлення з цільовими показниками:

• транзакційна істина та аудит — найсуворіші показники (відновлення за годину, втрата не більш ніж п'ять хвилин, тривалий строк зберігання, щомісячні часткові та щоквартальні повні навчання);
• операційна істина та проекції — менш суворі;
• аналітична істина та фічі моделей — м'які показники;
• архівні дані — тривале відновлення припустиме.

Вісім канонічних класів інцидентів з детальними процедурами реагування, постмортемами та поліпшеннями. Захист від вигоряння чергових команд: обмежена кількість тижнів чергування на інженера за встановлений інтервал залежно від фази.

5.6. Підтримуваність та продуктивність

• Чіткі обмежені контексти в коді;
• Hexagonal architecture з явними портами та адаптерами;
• Огляд коду для кожного злиття;
• Автоматизовані тести: модульні з покриттям доменного ядра не менше 80%, інтеграційні, контрактні, наскрізні, навантажувальні;
• Документація кожного сервісу в актуальному стані;
• Записи про архітектурні рішення для нетривіальних виборів;
• Час онбордингу нового розробника — не більш ніж два тижні до першого продуктивного злиття;
• Частка влучень у кеш для шляхів читання на B2C-вітрині більш ніж 85%;
• Затримка запитів до бази 95-го процентиля менш ніж 50 мілісекунд для канонічних читань;
• Затримка запитів до бази 95-го процентиля менш ніж 200 мілісекунд для транзакційних записів;
• Затримка типових пошукових запитів 95-го процентиля менш ніж 500 мілісекунд;
• Накладні витрати шлюзу менш ніж 10 мілісекунд (95-й процентиль).

6. Цільові обсяги

• Підтримка десятків тисяч пошукових запитів на день на ранній фазі;
• Підтримка мільйонів пошукових запитів на день на фазі зрілості;
• Підтримка десятків мільйонів пошукових запитів на день на фазі масштабування;
• Архітектура повинна горизонтально масштабуватися без переписування на кожному порядку зростання;
• Підключення кількох постачальників на ранніх фазах, десятків постачальників з різними форматами інтеграції на зрілих фазах без істотного рефакторингу ядра.

7. Підхід до реалізації

Платформа розробляється за фазовою моделлю з метричними та доменними тригерами переходу між фазами. Не календарний план, а рух за тригерами.

Жодних MVP-заглушок, захоплювальних інтеграцій під одного постачальника, тимчасових рішень без плану міграції. Кожне рішення проектується як зріле.

Чотири фази інфраструктурної зрілості

• Старт. Керовані сервіси бази даних, об'єктного сховища, контейнерної оркестрації в одному регіоні. Базова спостережуваність. Мінімально життєздатний набір канонічних доменів: міграція мульти-тенантності, статусна машина бронювання, платіжний домен, базова відповідність регуляторам, базова безпека, відновлення транзакційної істини.
• Ізоляція сервісів. Реплікація між зонами доступності для критичних даних. Автоматизоване щоденне тестове відновлення. Керована платформа секретів з автоматичною ротацією. Шина подій для доменних подій. Розширений пошуковий рушій. Стек спостережуваності з розрахунком метрик якості обслуговування. Формальна релізна інженерія з тарифо-залежним canary-викочуванням. Багаторівнева структура чергувань. Стабілізований партнерський програмний інтерфейс з пісочницею та сертифікацією. Перші корпоративно-значущі ML-застосування. Каркас експериментів у базовій реалізації. SIEM як окремий стек.
• Спеціалізована упаковка навантажень. Виділені обчислювальні потужності для критичного ядра. Виділені пули графічних процесорів для машинного навчання. Резервний регіон з холодним резервуванням для критичних даних. Крос-регіональна реплікація об'єктного сховища. Кластерне сховище даних для аналітики. Бойова платформа машинного навчання з вітриною ознак, реєстром моделей, системою видачі прогнозів, моніторингом моделей. Зріла каркас A/B-експериментів. Партнерський аналітичний продукт для преміум-рівнів із захистом від деанонімізації. Цілодобові чергування з покриттям за часовими поясами. Сервіс-меш з повним взаємним TLS. Зовнішні тестування на проникнення. Приватна програма баг-баунті. Корпоративний рівень обслуговування. Можливий перехід критичних шляхів на мову з гарантіями безпеки пам'яті за наявності вимірюваних причин.
• Багаторегіональна конфігурація та виділена інфраструктура. Багаторегіональна активно-активна або активно-пасивна конфігурація з автоматичним перемиканням. Розподілена база даних з багатомастер-записом. Розгортання в декількох зонах доступності для критичних операцій. Глобальна маршрутизація за DNS з перевіркою здоров'я. Виділена інфраструктура для корпоративних тенантів. Регіональна локалізація даних для регульованих юрисдикцій. Багаторегіональна спостережуваність з федерацією. Багаторегіональний SIEM. Формальні аудити SOC 2 Type 2 та рух до ISO 27001. Корпоративний рівень аварійного відновлення. Маркетплейс додаткових можливостей. Протидія відмиванню коштів та ідентифікація клієнтів через спеціалізованих провайдерів. Розширення в нові географії. Відповідальний за захист даних при досягненні регуляторних порогів. Безперервне тестування на проникнення. Публічна програма баг-баунті.

8. Сценарії end-to-end (для підтвердження архітектури)

Підрядник повинен звернути увагу, що архітектура має підтримувати такі end-to-end сценарії:

1. Пошук і бронювання одного об'єкта розміщення через B2C-вітрину із застосуванням комерційної політики, захопленням конверсійних подій, постпродажною комунікацією.
2. Пошук і бронювання одного об'єкта розміщення через партнерський програмний інтерфейс з тенант-залежною видимістю, динамічною тарифікацією, підтвердженням доставки сповіщень.
3. Створення складного багатокомпонентного туру з перевіркою сумісності компонентів, обробкою розбіжностей між станом на момент збирання та поточним станом постачальників, генерацією матеріалізованого артефакта (PDF, share-посилання).
4. Конверсія комерційної пропозиції туру в багатоброньовану транзакцію з координацією підтверджень від декількох постачальників, обробкою часткових відмов, атомарною фіксацією.
5. Скасування та зміна бронювання з координацією постачальника, розрахунком повернення, коригуванням розрахунків, оновленням партнерського балансу.
6. Зрив з боку постачальника всередині бронювання з альтернативним пошуком, комунікацією з клієнтом, фінансовим коригуванням.
7. Конвертація валют у транс'юрисдикційній транзакції (клієнт в одній країні, об'єкт в іншій, платіж у третій валюті).
8. Запит суб'єкта даних за GDPR (повний експорт + повне видалення з підтриманням журналу аудиту).
9. Повний життєвий цикл партнера — від реєстрації в середовищі тестування до сертифікації та бойового підключення.
10. Партнерський білінговий цикл з агрегацією споживання, тарифікацією, виявленням перевищення лімітів, генерацією рахунка, обробкою платежу.
11. A/B-експеримент на B2C-вітрині з розподілом користувачів за когортами, відстеженням показів, розрахунком статистичної значущості, прийняттям рішення.
12. Розгортання моделі машинного навчання для ранжування пошуку з одночасним експонуванням декількох версій та автоматичним відкатом при деградації.
13. Навчання з аварійного відновлення з відновленням з географічно надлишкової резервної копії в альтернативному регіоні з перевіркою цілісності даних та розрахунком порушення рівня обслуговування.

9. Що точно НЕ входить до завдання підрядника

• Маркетинг і продаж партнерів;
• Юридичне оформлення контрактів з постачальниками та партнерами;
• Дизайн брендингу B2C-вітрини (підрядник реалізує на готовому дизайні);
• Контент каталогу понад те, що приходить від постачальників;
• Прямі контракти з постачальниками;
• Прямий контракт з провайдером платежів;
• Реєстрація compliance-обов'язків у регуляторів.

Окремі scope за необхідності (не покриті цим завданням):

• Нативні мобільні застосунки для кінцевих клієнтів на ранніх фазах (тільки адаптивна веб-вітрина);
• Голосові інтерфейси або conversational AI;
• Блокчейн-компоненти;
• Пряма інтеграція з глобальними distribution systems для авіа на ранніх фазах;
• Розвинений клієнтський саппорт понад базовий тікетинг.

10. Резюме складності проекту

Платформа цього рівня — це:

• глобальна гнучка модульна B2B-платформа верхнього рівня, не один сайт і не одна інтеграція;
• понад 40 канонічних компонентів з різною складністю (від середньої до дуже високої);
• понад десяток end-to-end сценаріїв, кожен з яких охоплює декілька архітектурних шарів;
• чотири фази інфраструктурної зрілості з метричними та доменними тригерами переходу;
• регуляторне покриття декількох юрисдикцій, локалізації даних і податкових режимів;
• зріла операційна модель з багатовимірним відновленням, класами інцидентів, багаторівневими чергуваннями, явними метриками якості обслуговування та автоматичними компенсаціями при їх порушенні;
• архітектурна дисципліна, що не допускає «тимчасових рішень» — кожне рішення проектується як зріле та реалізується за фазами як розширення, не як міграція.

11. Що очікує замовник

• Розуміння приблизного обсягу робіт;
• ROM-оцінка з інтервалом ціни;
• Приблизний строк до MVP-версії;
• Приблизний технологічний стек;
• Відповідь на цей запит до 5 робочих днів на e-mail нашого представника, для розгляду підписання NDA.

Цей документ — витяжка для попередньої оцінки. Після підписання NDA підрядник отримує доступ до всіх документів платформи з чітко поставленими цілями.