Опубликовано: 02.10.2026 | Источник: CNews (новости)

Интеграция билетного сервиса в маркетплейс: тема ВКР с реальной архитектурой

26 марта 2026 года «М.Видео» объявил о запуске продаж билетов на концерты и стендапы прямо на своём сайте. Классический ритейлер электроники, который ещё недавно продавал только технику, теперь расширяет ассортимент до курток, сумок и билетов — фактически превращаясь в универсальный маркетплейс и одновременно в аналог «Яндекс Афиши». Для выпускника ИТ-направления это не просто новость из бизнеса. Это готовый полигон для ВКР: превратить монолитный e-commerce в гибридную платформу, где каталог товаров, билетный сервис и внешние поставщики работают в едином контуре. Рынок билетов плотно занят, и победит тот, у кого архитектура окажется гибче — а значит, тема отлично ложится в разделы проектирования и тестирования диплома.

Три темы ВКР, которые можно собрать из этой новости

Тема 1. Проектирование микросервисной платформы маркетплейса с подключением внешних поставщиков билетов

Актуальность: кейс «М.Видео» показывает, что ритейлеры выходят за пределы своей вертикали и подключают чужие сервисы. В дипломе это обосновывается через анализ рынка и требования к масштабируемости.

• Цель: разработать архитектуру платформы, в которой билетный сервис подключается как отдельный модуль без переписывания ядра каталога.
• Задачи: анализ существующих решений («Яндекс Афиша», «Кассир», Wildberries); выбор способа интеграции (REST, GraphQL, брокер сообщений); проектирование слоя API Gateway; описание схемы данных и отказоустойчивости.
• Структура: Глава 1 — обзор рынка и технологий интеграции; Глава 2 — проектирование (C4-диаграммы, схема развёртывания в Kubernetes); Глава 3 — тестирование, метрики SLA, экономика внедрения.

Тема 2. Разработка модуля поиска и рекомендаций для гибридного каталога

Актуальность: когда на одной витрине лежат ноутбуки, куртки и билеты на стендап, стандартный поиск по категориям ломается. Нужна система, которая умеет смешивать разнородные сущности.

• Цель: построить поисковый модуль с единой моделью товара/события и ранжированием.
• Задачи: проектирование единой схемы атрибутов; выбор поискового движка (Elasticsearch/OpenSearch); разработка алгоритма ранжирования; оценка качества по метрикам precision/recall.
• Структура: Глава 1 — теория информационного поиска; Глава 2 — архитектура индекса и API; Глава 3 — эксперименты и оценка релевантности.

Тема 3. Оценка готовности монолита к выделению билетного домена

Актуальность: не каждая компания может сразу перейти на микросервисы. Кейс «М.Видео» даёт повод защитить работу, где обосновывается поэтапная эволюция архитектуры.

• Цель: предложить методику оценки и дорожную карту выделения нового домена из монолита.
• Задачи: анализ связности модулей; расчёт метрик связанности и сцепления; построение целевой архитектуры; оценка рисков и RTO/RPO.
• Структура: Глава 1 — паттерны миграции (Strangler Fig, Branch by Abstraction); Глава 2 — модель оценки; Глава 3 — прототип и результаты.

Аналитическая глава: как обосновать выбор стека, а не просто его перечислить

Главная ошибка в первой главе — список технологий без критериев. Сравнивайте решения по метрикам из ISO/IEC 25010: производительность, совместимость, удобство сопровождения. Ниже — пример таблицы, которую можно вставить в диплом почти без правок.

Отдельно пропишите, какие протоколы и стандарты вы используете: REST или gRPC для синхронных вызовов, Apache Kafka или RabbitMQ для событий «билет продан». Ссылайтесь на источник новости как на подтверждение рыночной потребности — это усиливает аргументацию.

Проектная часть: схемы, алгоритмы, контракты

Здесь недостаточно одной UML-диаграммы классов. Покажите как минимум три уровня: контекстную диаграмму системы, схему интеграции с внешним билетным провайдером и диаграмму последовательности покупки. Например, последовательность «пользователь → API Gateway → сервис заказов → билетный провайдер → платёжный шлюз» отлично демонстрирует понимание распределённых транзакций.

Опишите идемпотентность операций и компенсирующие транзакции (паттерн Saga), потому что покупка билета — это классический пример, где нельзя допустить двойного списания. В дипломе это выглядит сильно, особенно если подкрепить фрагментом описания контракта API:

POST /api/v1/tickets/reserve
{
  "event_id": "evt_2026_standup_01",
  "quantity": 2,
  "idempotency_key": "user42-order-889"
}

Тестирование и метрики: где брать цифры для расчётов

Нагрузочное тестирование — то, чего чаще всего не хватает в ВКР. Используйте открытые инструменты (k6, Locust, JMeter) и снимайте показатели: время отклика p95/p99, пропускную способность, количество ошибок под нагрузкой. Для мониторинга опишите стек OpenTelemetry + Prometheus + Grafana — это уже отраслевой стандарт наблюдаемости.

Обязательно посчитайте RTO и RPO для сценария «упал билетный провайдер». Если система продолжает продавать технику и лишь временно скрывает блок билетов — это сильный архитектурный аргумент, подтверждающий изоляцию доменов.

FAQ по теме

Чему вы научитесь на такой теме

• Обосновывать архитектурные решения через критерии качества, а не «мне так нравится».
• Проектировать интеграции между собственными и внешними сервисами с учётом отказов.
• Снимать и интерпретировать метрики производительности и надёжности.
• Оформлять техническую документацию по ГОСТ и защищать её перед комиссией.
• Связывать бизнес-кейс из новостей с инженерными решениями — именно это ценят на защите.

Если самостоятельно разобраться с методологией сложно, помогает разбор чужой работы или консультация с практиком: как написать ВКР так, чтобы каждый раздел опирался на источник и метрику, а не на общие слова.

Источник: Гигантский ритейлер электроники бросил вызов «Яндексу» и «Кассиру». Теперь он продает билеты на концерты и мимикрирует под Wildberries (опубликовано 2026-03-26)