Проектирование книжного сервиса для ВКР: разбор кейса запуска «WB Книги»
30 марта 2026 года объединённая компания RWB (Wildberries & Russ) открыла тестовый доступ к приложению «WB Книги». Формально это новость из мира e-commerce, но для выпускника ИТ-направления это готовый полигон для ВКР: сервис поднимает сразу несколько «дорогих» тем — стриминг и скачивание контента с DRM, каталог с рекомендациями, интеграция с существующей инфраструктурой маркетплейса, отказоустойчивость и пиковая нагрузка в момент промо-акций. Плюс всё это живёт на фоне обновления требований к документированию (ГОСТ 34.602-89, ГОСТ Р 19.201) и ужесточения критериев качества по ISO/IEC 25010. Дальше — как превратить эту новость в план работы, что писать в каждой главе и какие метрики защищать перед комиссией.
Почему кейс «WB Книги» удобен как «якорь» для диплома
У новости три свойства, критичных для защиты. Во-первых, есть реальная дата и первоисточник — комиссия любит, когда актуальность подкреплена конкретным событием, а не фразой «в современном мире растёт популярность». Во-вторых, сервис находится в тестовом режиме: это честно даёт вам право писать не про «готовую систему», а про пилотную архитектуру и сценарии масштабирования — звучит взрослее, чем учебный CRUD. В-третьих, книжный стриминг — это сразу узел из пяти подсистем: identity, каталог (каталогизация + поиск), DRM-защита контента, доставка через CDN, аналитика и рекомендации. Один кейс — пять направлений для ВКР разной степени «дороговизны».
Три темы ВКР, которые «пристёгиваются» к новости
Тема 1. Проектирование сервиса доставки книжного контента внутри экосистемы маркетплейса
Актуальность. Запуск «WB Книги» в тестовом режиме показывает, что крупные российские платформы разворачивают контентные направления «поверх» товарного ядра. Значит, инженеру нужна архитектура, где каталог, биллинг и доставка масштабируются независимо.
Цель. Разработать архитектуру сервиса доставки книжного контента, обеспечивающую целевую задержку выдачи страницы и защиту от нелегального распространения файлов.
Задачи.
- Проанализировать существующие книжные платформы и модели монетизации (подписка, покупка, аренда).
- Обосновать декомпозицию на сервисы (каталог, DRM, доставка, платежи, телеметрия) и стек.
- Построить C4-диаграммы контейнеров и компонентов, описать контракты API в OpenAPI 3.1.
- Провести нагрузочное тестирование сценария «скачивание + чтение онлайн» и зафиксировать SLO.
Структура. Глава 1 — обзор рынка, DRM-подходов (Adobe ADEPT, Readium LCP) и архитектурных паттернов. Глава 2 — проектирование: логическая и физическая модели, диаграммы, спецификация API. Глава 3 — тестирование, метрики производительности и расчёт стоимости владения (TCO) на 12 месяцев.
Тема 2. Модуль рекомендаций книжного каталога на основе поведения пользователя
Актуальность. В пилоте «WB Книги» конкуренция идёт не за каталог (он огромен), а за удержание. Персональные рекомендации — прямой механизм удержания, и это отличная прикладная задача для ВКР.
Цель. Разработать рекомендательный модуль, повышающий конверсию из «просмотрел книгу» в «начал читать».
Задачи. Спроектировать схему сбора событий (просмотр, чтение, добавление в избранное), построить feature store, реализовать гибридную модель (коллаборативная фильтрация + контентные признаки), оценить эффект через off-line метрики (Recall@10, NDCG) и A/B-тест.
Структура. Глава 1 — обзор рекомендательных подходов и ограничений cold-start. Глава 2 — архитектура пайплайна: брокер событий, хранилище признаков, сервис инференса. Глава 3 — экспериментальная оценка и экономический эффект от роста конверсии.
Тема 3. Построение наблюдаемости книжного сервиса: SLO и бюджет ошибок
Актуальность. Тестовый режим — это по сути пилот, и перед коммерческим запуском нужно уметь доказывать, что система не деградирует. Это чётко ложится на требования ISO/IEC 25010 в части надёжности и производительности.
Цель. Разработать систему мониторинга и алертинга для книжного сервиса на базе OpenTelemetry с формализованными SLO.
Задачи. Определить пользовательские сценарии и SLI, настроить сбор метрик и трассировки, построить дашборды, рассчитать бюджет ошибок и пороги алертов.
Структура. Глава 1 — теория наблюдаемости, метрики «золотого сигнала», нормативка. Глава 2 — выбор стека (Prometheus, Grafana, Tempo) и схема инструментирования. Глава 3 — эксперименты, деградации, отчёт о достижимости SLO.
Аналитическая глава: как обосновать стек без «воды»
Типичная ошибка — написать «выбрали микросервисы, потому что они масштабируемые». Вместо этого сделайте сравнительную таблицу с явными критериями и весами. Критерии можно взять из ISO/IEC 25010: производительность, надёжность, сопровождаемость, переносимость. Оценки — 1–5, вес × оценка, итоговый рейтинг. Комиссия видит методику, а не веру.
| Критерий (вес) | Монолит | Микросервисы | Serverless |
|---|---|---|---|
| Скорость вывода MVP (0,25) | 5 | 2 | 4 |
| Независимое масштабирование доставки/CDN-слоя (0,25) | 2 | 5 | 4 |
| Наблюдаемость и отладка (0,2) | 5 | 3 | 2 |
| Стоимость при пиковых промо-нагрузках (0,15) | 3 | 4 | 2 |
| Соответствие ГОСТ 34.602-89 при документировании (0,15) | 5 | 3 | 3 |
| Итоговый балл | 3,95 | 3,45 | 3,05 |
Такой расчёт — сильный ход: вы не «топите» за модный подход, а показываете инженерную честность. И, кстати, это хороший аргумент, почему в учебном проекте допустим модульный монолит с выделенным сервисом доставки — защита будет выглядеть взрослее, чем механическое «делаем микросервисы».
Проектная часть: что рисовать и как описывать интеграции
Минимум для книги 2 — три уровня диаграмм: контекст (C4-L1), контейнеры (C4-L2) и последовательность сценария «покупка → выдача DRM-лицензии → скачивание». UML-диаграммы размещайте в приложении, а в тексте оставляйте только те, без которых выводы не читаются. Проверяйте каждую стрелку: у каждой должен быть протокол и направление инициативы.
Контракты API опишите в OpenAPI 3.1 — это снимает половину вопросов комиссии про «как модули разговаривают». Полезно добавить фрагмент спецификации:
paths:
/v1/books/{isbn}/license:
post:
summary: Выдать DRM-лицензию на книгу
parameters:
- name: isbn
in: path
required: true
schema: { type: string, pattern: '^978[0-9]{10}$' }
responses:
'201': { description: Лицензия выдана, TTL 72ч }
'409': { description: Лицензия уже активна }
'402': { description: Требуется оплата или активная подписка }Отдельно проговорите интеграцию с существующим маркетплейсом: единая авторизация (OIDC), единый идентификатор пользователя, события заказа в общую шину. Именно это в статье названо «объединённой компанией» — то есть сервис не отдельная вселенная, а модуль экосистемы. В дипломе это раздел «интеграционные ограничения».
Тестирование и метрики: чем измерять результат
Глава 3 часто проваливается, потому что студент пишет «система работает стабильно». Стабильность — не аргумент. Нужны величины и условия замеров. Для книжного сервиса разумный набор:
| Метрика | Инструмент | Целевое значение |
|---|---|---|
| p95 задержки каталога | k6 / JMeter + OpenTelemetry | ≤ 300 мс |
| p95 задержки выдачи лицензии | k6 | ≤ 600 мс |
| Пропускная способность скачиваний | CDN-логи | ≥ 2 000 RPS на пилотном стенде |
| RTO / RPO при отказе узла | Сценарий chaos-теста | 15 мин / 5 мин |
| Доля ошибок 5xx | Prometheus | < 0,1% |
| Бюджет ошибок за 30 дней | Grafana SLO-панель | ≥ 70% доступности бюджета |
Хорошо работают SLO-панели — это визуально понятный артефакт на защите. Например, выражение для расчёта доли успешных запросов каталога:
sli:sum(rate(http_requests_total{job="catalog",code!~"5.."}[5m]))
/ sum(rate(http_requests_total{job="catalog"}[5m]))Ещё один «дорогой» аргумент — RTO/RPO-сценарий. Покажите, что при падении узла доставки лицензии разговор продолжается: трафик уходит на резервный кластер, лицензии выдаются из кэша, каталог деградирует только в части рекомендаций. Такой сценарий превращает главу из «тесты прошли» в осмысленный инженерный разбор.
Чему вы научитесь, пока будете это делать
- Декомпозировать продукт на сервисы по границам ответственности, а не по «удобству разработчика».
- Обосновывать выбор технологического стека через критерии и веса, а не через популярность.
- Строить C4/UML-модели и сопровождать их текстом, а не сдавать «картинку ради картинки».
- Писать OpenAPI-контракты и проектировать события для брокеров сообщений.
- Снимать метрики производительности, считать SLO и формулировать отчёт о нагрузочных испытаниях.
- Оформлять ТЗ и пояснительную записку в соответствии с ГОСТ 34.602-89 и ГОСТ Р 19.201.
- Подмена понятий «сервис», «микросервис», «модуль» без обоснования. Решение: заведите в начале главы глоссарий на 5–7 терминов и придерживайтесь его до конца. Комиссия любит единообразие.
- Отсутствие измеримых метрик эффективности. Решение: до начала тестов зафиксируйте три-четыре числа (например, p95 задержки и целевой RPS), а в выводах сравните «план / факт».
- Игнорирование ГОСТ 34.602-89 при оформлении ТЗ. Решение: возьмите структуру ТЗ из стандарта (общие сведения, назначение, требования к системе, этапы разработки) и наполните её — потеряете меньше баллов на нормоконтроле.
FAQ: частые вопросы по теме
Насколько сложно реализовать прототип книжного сервиса за один семестр?
Если претендовать на прод-уровень с DRM и CDN — нереально. Если взять «тонкий срез»: каталог, поиск, оформление заявки на лицензию и заглушку выдачи — вполне. Ключ в том, чтобы в цели явно ограничить периметр: «прототип подсистемы каталога и выдачи лицензий». Комиссия принимает честные ограничения лучше, чем размытые обещания.
Обязательно ли писать код в ВКР по такому кейсу?
Формально нет — бывают проектные работы с уклоном в моделирование. Но если в задачах есть «разработать», «реализовать», «проверить на нагрузке», код и стенд нужны. Минимальный разумный набор — репозиторий с Docker Compose, миграциями и нагрузочным скриптом. Тогда вы отвечаете на вопросы по существу, а не пересказываете текст.
Как оформить UML/C4-диаграммы, чтобы их приняли?
Единый нотационный стиль на всю работу, подпись «Рисунок N — Название», ссылка на рисунок в тексте до его появления. Инструменты: draw.io, PlantUML, Structurizr (для C4). Обязательно приложите легенду, если вводите нестандартные обозначения — это спасает на защите.
Где брать тестовые данные для каталога и рекомендаций?
Открытые книжные каталоги с метаданными (например, Open Library), синтетические события просмотров, сгенерированные по распределению Ципфа — оно хорошо имитирует реальное поведение читателей. Публичные датасеты для рекомендаций (Book-Crossing) годятся как источник для off-line оценки. Главное — указать в работе происхождение и лицензию данных.
- Ссылка на первоисточник новости указана в разделе актуальности и в списке литературы.
- Каждая задача из введения отражена в выводах по главам и в заключении.
- На все рисунки и таблицы есть ссылки в тексте; сквозная нумерация не сбита.
- ТЗ оформлено по ГОСТ 34.602-89, перечень сокращений и глоссарий заполнены.
- Метрики производительности зафиксированы с условиями замера (объём данных, число виртуальных пользователей).
- Список литературы: не менее 30 источников, из них не менее 5 — за последние 3 года.
- Приложение содержит спецификацию API, скрипты нагрузочных тестов и схему развёртывания.
Если кажется, что кейс интересный, но непонятно, с чего начать — приходите на бесплатную консультацию. Мы разберём вашу тему, подскажем, как сформулировать цель и задачи, и предложим пошаговый план на 120 часов работы. Помогаем с любой темой: от нагрузочного тестирования до проектирования микросервисной архитектуры. Заказать диплом или ВКР на заказ можно и точечно — только по одному разделу, например по главе с тестированием.
Источник: RWB запускает в тестовом режиме сервис «WB Книги» для всех желающих (опубликовано 2026-03-30)