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

Мини-приложения VK в дипломе: сервис бронирования экскурсий как кейс для ВКР

25 марта 2026 года CNews сообщил: VK расширяет проект «VK Места» — теперь прямо в мини-приложении можно бронировать и оплачивать экскурсии по регионам России. За этой новостью стоит не «ещё один маркетплейс», а полноценная распределённая система: каталог туров, расписания, проверка доступности мест, платежи, отмены, возвраты и уведомления. Для выпускника ИТ-направления это идеальный полигон для ВКР: кейс свежий, подтверждён индустрией, но при этом его можно сузить до одной защищаемой задачи — и не утонуть в масштабе VK.

Ниже — разбор, как превратить эту новость в главы 1–3, какие диаграммы рисовать, какие метрики считать и где студенты чаще всего спотыкаются. Поддомен — Backend / интеграции, роль эксперта — Архитектор ПО и системный аналитик.

Частые вопросы студентов по теме

Темы ВКР: три варианта под разную глубину

• Тема 1. Проектирование сервиса бронирования экскурсий в мини-приложении VK

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

  Цель: разработать сервис бронирования, исключающий двойное резервирование места и обеспечивающий предсказуемое время отклика.

  Задачи: анализ предметной области и аналогов; построение модели данных; проектирование API и схемы транзакций; реализация и нагрузочное тестирование.

  Структура: Глава 1 — анализ рынка экскурсионных сервисов, BPMN процесса «выбор — бронь — оплата»; Глава 2 — C4-диаграммы, схема БД, спецификация REST/OpenAPI; Глава 3 — тесты, метрики p95, отчёт по двойным бронированиям.

• Тема 2. Идемпотентность и надёжность платежей в сервисе бронирования

  Актуальность. Платёжный сценарий в мини-приложении — самое хрупкое место: двойное списание или «зависшая» бронь убивают доверие пользователя быстрее, чем медленный интерфейс.

  Цель: обеспечить ровно-однократную обработку платёжных событий при повторных доставках вебхуков.

  Задачи: обзор моделей согласованности; проектирование идемпотентного ключа и журнала операций; реализация обработчика вебхуков; имитация сбоев и замер восстановления.

  Структура: Глава 1 — теория идемпотентности, паттерны Saga и Outbox; Глава 2 — проектирование схемы payment_intent, очередь, ретраи с экспоненциальной задержкой; Глава 3 — chaos-тесты, метрика «доля потерянных платежей».

• Тема 3. Наблюдаемость и мониторинг распределённого сервиса бронирования

  Актуальность. Пока бронирование работает внутри экосистемы соцсети, сбой оплаты замечают миллионы пользователей — значит, наблюдаемость перестаёт быть «дополнительной главой».

  Цель: построить контур мониторинга, сокращающий время обнаружения инцидента (MTTD) и восстановления (MTTR).

  Задачи: выбрать сигналы и SLI; внедрить трассировку и сбор метрик; настроить алертинг по SLO; провести эксперимент с искусственной деградацией.

  Структура: Глава 1 — обзор OpenTelemetry и подходов SRE; Глава 2 — схема пайплайна метрика → хранилище → дашборд → алерт; Глава 3 — сравнение MTTD/MTTR до и после внедрения.

Как разложить кейс по главам ВКР

Глава 1: анализ предметной области и требования

Начните не с технологий, а с процесса. Опишите путь пользователя: выбор экскурсии в каталоге → выбор слота → подтверждение → оплата → получение ваучера → возможная отмена. Этот путь удобно оформить в BPMN 2.0: пул пользователя, пул сервиса, пул платёжного провайдера, пул туроператора. Именно на стыке пулов вылезают будущие требования — таймауты подтверждения от оператора, правила возврата, ограничения по количеству мест.

Требования оформляйте по ISO/IEC 25010, разбивая на функциональную пригодность, производительность, надёжность и безопасность. Это сразу даёт вам каркас для Главы 3: каждое нефункциональное требование должно превратиться в измеримую метрику. Если пишете ТЗ по ГОСТ 34.602, раздел «Требования к системе» соберётся из этих же формулировок почти без переписывания.

Глава 2: проектирование и реализация

Минимум три диаграммы, которые спросят на защите: контекстная C4 (уровень 1) — сервис, VK ID, платежный шлюз, внешние API туроператоров; C4-контейнеры (уровень 2) — API Gateway, сервис бронирования, сервис платежей, БД, очередь; диаграмма состояний брони. Последняя критична — она снимает половину вопросов про гонки.

Состояния бронирования:
  CREATED ──hold──▶ HELD ──pay──▶ PAID ──confirm──▶ CONFIRMED
     │               │              │                  │
     │               │              │                  ▼
     └──expire──▶ EXPIRED      FAILED            CANCELED ──▶ REFUNDED

Ключевое место — переход HELD → PAID: два пользователя одновременно жмут «оплатить» на последнее место. Покажите, как это решается блокировкой на уровне БД или распределённым локом. Пример компактного идемпотентного обработчика:

async def handle_payment_event(event, db, redis):
    # 1. Идемпотентный ключ: провайдер + идентификатор платежа
    key = f"pay:{event.provider_id}:{event.payment_id}"

    # 2. Атомарная попытка занять ключ на 24 часа
    acquired = await redis.set(key, "processing", nx=True, ex=86400)
    if not acquired:
        return {"status": "duplicate_ignored"}

    async with db.transaction():
        booking = await db.get_booking_for_update(event.booking_id)  # FOR UPDATE
        if booking.state != "HELD":
            return {"status": "state_conflict", "current": booking.state}

        booking.state = "PAID"
        await db.insert_payment_log(event, idempotency_key=key)

    await redis.set(key, "done", ex=86400)
    return {"status": "ok"}

Обратите внимание на два момента, которые любят комиссии. Первый — блокировка строки (SELECT ... FOR UPDATE) работает только внутри одной транзакции, не растягивайте её на вызов внешнего API. Второй — журнал платежей с уникальным индексом по идемпотентному ключу даёт вам «второй эшелон защиты», если Redis недоступен.

Глава 3: тестирование, метрики, экономика

Здесь ВКР перестаёт быть рефератом. Соберите две группы метрик: технические и продуктовые. Первые подтверждаются прогоном, вторые — моделью или симуляцией.

Для трассировки и метрик берите OpenTelemetry: одна инструментация — и вы получаете и трейсы, и гистограммы задержек, и контекст для логов. Это же снимает вопрос «а как вы связываете ошибку у пользователя с конкретным запросом в БД?».

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

• Проектировать доменную модель с состоянием и переходами, а не «таблицу заказов с полем status».
• Защищать критические секции: блокировки, идемпотентные ключи, повторные доставки.
• Строить диаграммы C4, BPMN и UML State, которые не стыдно показать комиссии.
• Считать нефункциональные метрики и доказывать их нагрузочным тестом.
• Оформлять требования по ISO/IEC 25010 и техническое задание по ГОСТ 34.602.

Источник: Пользователи «ВКонтакте» смогут бронировать в соцсети экскурсии по регионам России (опубликовано 2026-03-25)