Кейс Scholarly: запуск универсальной LMS на 15 000 пользователей на WebRTC и микросервисах

Подробнее по теме: читайте наше полное руководство — AI-аналитика видео для онлайн-обучения (2026).

Почему Фора Софт публикует этот кейс

Фора Софт уже десять лет выпускает образовательные продукты с видео в основе. Scholarly — один из самых наглядных примеров закономерности, которая повторяется во всём нашем портфолио EdTech-проектов: образовательный бизнес перерастает лоскутное одеяло из сторонних инструментов, переходит на единую платформу, построенную под его задачи, и выходит на пятизначное число одновременных пользователей без того, чтобы всё рухнуло.

Мы публикуем этот кейс, потому что чаще всего основатели образовательных проектов спрашивают нас: «а нам действительно нужна своя LMS?». Иногда — нет: Thinkific, Moodle, TalentLMS или Teachable вас закроют. Иногда — да: если прямые лекции на реальном масштабе, видимость для родителей и отлаженные процессы администрирования и есть ядро продукта, готовое решение упрётся в потолок в течение года. Scholarly был как раз случаем «да», и архитектура, расчёт стоимости и компромиссы ниже объясняют почему.

Если вы взвешиваете похожий шаг, та же команда, что выпустила Scholarly, делает и прямые занятия для BrainCert, голосовых и видеоагентов на LiveKit, а также платформы по разработке программного обеспечения на заказ для остальных наших клиентов.

Scholarly вкратце

Проблема: Zoom + Discord — это не LMS

До Scholarly клиент вёл занятия в Zoom, сообщество в Discord, учебные материалы в Google Drive, расписание в таблицах, а биллинг — в отдельном SaaS-сервисе. Каждый новый поток студентов удваивал затраты на координацию. Решение строить собственную платформу продиктовали четыре конкретные болевые точки.

1. Разрозненные данные о студентах. Посещаемость — в логах Zoom. Домашние задания — в Drive. Оценки — в таблице. Ни у кого не было единого дашборда, чтобы ответить на вопрос «как у этого студента дела?». Признаки оттока оставались невидимыми, пока не отклонялся платёж.

2. Нет видимости для родителей. Родители в сегменте школьного и среднего профессионального образования регулярно спрашивают: «что мой ребёнок изучает на этой неделе?». Выдать им ссылки на Zoom и PDF с расписанием — это не продукт, это конвейер обращений в поддержку.

3. Потолки по вместимости. Zoom упирается примерно в 1 000 участников на встрече без корпоративной лицензии; он не рассчитан на модель «лекция с доской» для 2 000 студентов и без поддержки ИТ-отдела.

4. Перегрузка администраторов. Создать новый курс сразу в пяти инструментах — двухчасовой ритуал. При 15 000 пользователей и десятках курсов в неделю одни только сэкономленные часы администрирования окупали разработку уже в первый год.

Архитектура, которую мы выпустили

Scholarly — это система микросервисов, размещённая на Kubernetes. Плоскость прямых занятий, плоскость контента и плоскость идентификации — это отдельные сервисы, общающиеся через GraphQL и gRPC, так что крупная лекция никогда не ломает консоль администратора и наоборот.

Рисунок 1. Эталонная архитектура Scholarly: отдельные плоскости видео в реальном времени, контента и идентификации за GraphQL API.

Веб-приложение (React + Next.js)

Next.js обеспечивает рендеринг на стороне сервера для маркетинговых и публичных страниц курсов, а клиентский React — для авторизованных интерфейсов студента и преподавателя. Единая дизайн-система покрывает четыре роли (преподаватель, студент, родитель, администратор), поэтому мы не поддерживаем четыре продукта, притворяющихся одним.

Сервисы (микросервисы на Go + Node.js)

Go — для сервисов, чувствительных к задержке (оркестрация прямых сессий, присутствие, расписание). Node.js — для слоёв с интенсивным вводом-выводом и быстрыми итерациями (уведомления, приём контента, интеграции). Поверх — федерация GraphQL, чтобы веб-приложение запрашивало ровно то, что ему нужно, за один запрос.

Прямое видео (WebRTC + LiveKit)

Активные спикеры (преподаватель и несколько студентов одновременно) работают на WebRTC SFU на базе LiveKit. Пассивные студенты подключаются через DASH / HLS, поэтому мы не платим за SFU за весь остальной поток зрителей. Задержка от рта до уха остаётся ниже 300 мс для активного слоя и 2–4 секунды для слоя HLS — этого вполне достаточно для лекции на 2 000 мест.

Записи и контент

Каждая прямая сессия записывается, перекодируется в ABR-лестницу и отправляется на источник за CDN. Студенты навёрстывают материал в удобном для себя темпе. Домашние задания, слайды и дополнительные материалы лежат в объектном хранилище с подписанными URL и ролевым контролем доступа.

Данные и аналитика

За каждым сервисом — Postgres; для аналитики — хранилище данных; для эксплуатации — Prometheus + Grafana. Дашборд администратора отвечает на вопросы «кто присутствовал», «кто сдал», «кто в зоне риска» одним запросом, потому что эти данные теперь живут в одной системе.

Четыре роли, одна платформа

Преподаватели

Прямые лекции с демонстрацией экрана, виртуальной доской, общими учебными материалами и текстовым чатом. Каждая лекция вмещает до 2 000 студентов, записывается автоматически и попадает обратно в библиотеку курса без ручной загрузки. Преподаватели видят всё своё расписание на одном дашборде; время на подготовку к лекции сократилось примерно с 20 минут на занятие (раскиданных между Zoom, Drive и таблицами) до менее чем пяти.

Студенты

Подключаются к прямым трансляциям, смотрят записи, проходят тесты, сдают домашние задания и получают обратную связь от преподавателя — всё в одном интерфейсе. Посещаемость, оценки и прогресс отображаются в личном дашборде. Больше не нужно искать прошлонедельное домашнее задание по ссылкам Zoom, документам Google и почтовым перепискам.

Родители

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

Администраторы и суперадминистраторы

Администраторы получают консоль только для просмотра курсов, расписаний и записей на курсы. Суперадминистраторы получают полное управление данными (CRUD) — создание курсов, планирование событий (трансляций, встреч, открытых занятий), загрузку материалов, управление пользователями и группами и аудит всего каталога. Многоуровневые права доступа были обязательным условием для клиента, который ведёт несколько программ и привлекает внешних преподавателей.

Своя платформа против готовой LMS: как принимали решение

Владельцы Scholarly сначала присматривались к Thinkific, Teachable, LearnWorlds, Moodle и Open edX. Список сократился до своей разработки по трём причинам, с которыми готовые инструменты не справлялись:

1. Масштаб прямого видео. Готовые LMS встраивают Zoom / Vimeo / YouTube. Ни одна из них изначально не поддерживает интерактивные лекции на 2 000 мест с доской в едином потоке.

2. Многоролевая архитектура. Доступ родителя только для чтения, ограниченный его детьми, — это не функция из коробки. Это продукт.

3. Точность административных процессов. У клиента был свой недельный ритм создания курсов, планирования и кросс-курсового ценообразования. Гнуть универсальную LMS под него обходится в обходных решениях дороже, чем один раз построить нужные процессы.

Подход к разработке, который мы переиспользуем с каждым EdTech-клиентом

Шаг 1 — архитектура информации вокруг ролей. Сопоставьте каждое действие с ролью ещё до того, как откроете файл в Figma. Scholarly было бы невозможно использовать, если бы мы начали со «страницы курса» вместо «что делает преподаватель, что делает студент, что видит родитель, что может менять администратор».

Шаг 2 — выберите видеоплоскость заранее. WebRTC SFU (LiveKit, mediasoup) для интерактивности, HLS / DASH для пассивного большинства, записи на CDN. Подробный разбор компромиссов — в нашем руководстве по масштабируемому видеостримингу и видеоконференциям.

Шаг 3 — контракт GraphQL между вебом и сервисами. Один обход сети на экран. Федерация по сервисам, чтобы каждая команда владела своим куском. Окупается в момент, когда у вас появляется три продуктовых поверхности (веб, мобильные устройства, администрирование).

Шаг 4 — Kubernetes с первого дня. Не потому, что он нужен вам на старте, а потому, что первый крупный поток студентов поднимет вопросы по подам, ресурсам и масштабированию, которые вы не захотите дорабатывать задним числом. Helm + ArgoCD для деплоев.

Шаг 5 — наблюдаемость раньше аналитики. Prometheus, Grafana, структурированные логи, оповещения при 70% загрузки. Аналитика придёт позже; доступность пути прямого занятия ждать не может.

Реалистичный расчёт стоимости для LMS уровня Scholarly

Цифры ниже — это то, что мы реально называем в 2026 году, с Agent Engineering и в дизайне, и в инженерии. Традиционные агентства обычно выходят на 30–40% дороже при том же объёме работ. Если вы сравниваете сметы и наша выглядит оптимистично — вот почему.

Инфраструктура — сверху: на отметке в 15 000 пользователей для продакшен-LMS такой формы рассчитывайте на 225–600 тыс. ₽/мес, в основном за счёт исходящего трафика на записях и хостинга SFU во время пиков прямого эфира.

Схема принятия решения — стоит ли строить свою LMS?

В1. Прямой эфир — это продукт или функция? Live-first — почти всегда выигрывает своя разработка. Только функция — Thinkific + Zoom дешевле.

В2. Сколько одновременных студентов на одной сессии? < 200 — встроенный Zoom подойдёт. 200–1000 — серьёзный повод задуматься об SFU. > 1000 — гибрид из своего WebRTC + HLS остаётся единственным устойчивым ответом.

В3. Сколько различных ролей пользователей вам нужно? Две (преподаватель + студент) — тривиально. Четыре и больше (плюс родитель, администратор, суперадминистратор, внешний преподаватель) — это уже там, где готовые системы начинают навязывать неуклюжие обходные решения.

В4. Насколько уникальны ваши административные процессы? Стандартный «список курсов» подходит любому SaaS. Ценообразование, зависящее от типа места + сезона + потока + промокода — нет.

В5. Планируете ли вы добавлять AI-функции? Автопроверка, AI-репетиторство, расшифровка, персонализированные траектории. Готовые LMS выпускают это медленно или через громоздкие интеграции. Своя разработка позволяет выбирать модели, размещать их там, где нужно, и управлять кривой расходов.

Пять ловушек, которые мы видим почти в каждой EdTech-разработке

1. Сначала «страница курса», а потом модель ролей. Вы получаете красивую демонстрацию и продукт, которым невозможно управлять на масштабе.

2. Один видеосервис на всё. SFU для лекции на 2 000 мест — расточительно; HLS для интерактивного семинара — слишком большая задержка. Используйте оба, разделяя по тому, кто говорит.

3. Игнорирование записей. Участникам нужен асинхронный доступ. LMS без записей с поиском и индексацией теряет половину своей ценности.

4. Слабые интерфейсы для родителей или администраторов. Школьные и обучающие программы держатся на видимости для родителей; корпоративные клиенты — на административной отчётности. Выпускать продукт без них — ложная экономия.

5. Недооценка наблюдаемости. У прямых занятий нет второго шанса. Оповещения при 70% загрузки на SFU, перекодировщике и источнике — это разница между мелким сбоем и гневной перепиской с клиентом.

KPI, которые современная LMS обязана выводить на дашборд

KPI качества. Успешность подключения к прямому занятию (≥ 99%), задержка активного спикера по P95 (< 300 мс), доля ребуферизации на HLS (< 1%), доля отвалов в конце сессии (< 2%). Если какой-то из этих показателей проседает, остановите работу над новыми функциями и почините канал.

Бизнес-KPI. Доля прохождения курсов до конца, доля сдачи заданий, активные учащиеся в неделю, отток по потокам, доля входов родителей. Они определяют, какие функции получают приоритет.

KPI надёжности. Доступность 99,95%+ на пути прямого занятия, доля неудачных деплоев < 2%, MTTR < 30 минут в учебные часы, доля успешных бэкапов 100%.

Когда не стоит строить свою LMS

Менее ~500 активных пользователей и редкие прямые занятия. Teachable / Thinkific + Zoom — вполне нормальный стек; своя разработка не окупится в первые два года.

Чистая библиотека контента, без прямого эфира. Podia, Kajabi, Thinkific. Не переусложняйте видеоплоскость, которой вы никогда не воспользуетесь.

Нет владельца продукта, которого вы можете защитить. Своя LMS — это продукт, а не проект. Если внутри компании никто не возьмёт на себя дорожную карту, внедрение и метрики — готовое решение будет добрее.

Жёсткий срок вывода на рынок менее 6 недель. Запускайтесь на SaaS, мигрируйте, когда экономика перевернётся.

Частые вопросы

Сколько пользователей на самом деле обслуживает Scholarly?

Около 15 000 активных пользователей во всех ролях на момент написания, с прямыми лекциями, вмещающими до 2 000 студентов каждая. Рост из года в год был стабильным по мере того, как клиент запускал новые программы внутри той же платформы.

На каком технологическом стеке построен Scholarly?

React + Next.js на фронтенде; микросервисы на Go и Node.js на бэкенде; GraphQL как единый слой API; WebRTC через LiveKit для интерактива в реальном времени с DASH / HLS для пассивных зрителей и записей; Kubernetes для оркестрации; Postgres для реляционных данных; объектное хранилище + CDN для контента.

Сколько стоит построить платформу вроде Scholarly?

С Agent Engineering LMS на четыре роли с упором на прямой эфир укладывается в диапазон 13–26 млн ₽ примерно за 4–7 месяцев. Меньший MVP (две роли, прямые занятия до 200 мест) — это 6,7–12 млн ₽ за 8–14 недель. Традиционные агентства обычно выходят на 30–40% дороже при том же объёме. Инфраструктура сверху — обычно 225–600 тыс. ₽ в месяц при 15 000 активных пользователей.

Почему WebRTC + HLS, а не просто встроенный Zoom?

Zoom — это встреча, а не платформа. Вы не можете настроить доску под себя, не можете включить запись в свою библиотеку курсов, не можете масштабировать одну лекцию за пределы лимитов Zoom и не можете управлять соотношением задержки и стоимости. Гибридный стек WebRTC + HLS позволяет вести интерактивный «первый ряд» (преподаватель + активные студенты) на SFU с задержкой < 300 мс и пассивный «задний ряд» (сотни или тысячи зрителей) на HLS через CDN — на порядки дешевле.

Поддерживает ли Scholarly мобильных клиентов?

Да — адаптивное веб-приложение работает на мобильных устройствах уже сегодня, а нативные iOS / Android в дорожной карте. Большинству EdTech-клиентов мы рекомендуем начинать с адаптивной веб-версии и выпускать нативные приложения, когда аналитика покажет существенную мобильную аудиторию и конкретные потребности, которые закрываются только нативно (офлайн-воспроизведение, push-уведомления за пределами веб-пушей).

Действительно ли родители могут видеть прогресс своих детей?

Да. Роль родителя — только для чтения, но с ограничением: родитель видит только курсы своего ребёнка, расписание, сданные домашние задания и обратную связь от преподавателя. Одно это убрало заметную долю входящих обращений в поддержку у клиента.

Сколько времени занимает разработка LMS вроде Scholarly?

Первая рабочая версия с двумя ролями, небольшими прямыми занятиями и базовыми записями готова за 8–14 недель. Полный эквивалент Scholarly с четырьмя ролями, прямыми лекциями на 2 000 мест, доской, проверочными заданиями и полноценной консолью администратора занимает 4–7 месяцев. После запуска мы обычно тратим около 15–20% бюджета разработки в год на итерации, наблюдаемость и новые функции.

Можно ли добавить AI-функции поверх такой LMS?

Безусловно, и архитектура построена так, чтобы это поддержать. Мы уже добавляем расшифровку, проверку заданий с помощью AI и персонализированные траектории обучения для нескольких клиентов. Сопутствующие руководства по персонализированным учебным материалам, AI-инструментам для обучающего видео и автоматической генерации планов уроков описывают подходы, которые мы переиспользуем.

Что почитать дальше

Готовы превратить Zoom + таблицы в платформу?

Scholarly начинал там, где буксует большинство EdTech-бизнесов: сторонние инструменты, скотчем примотанные вокруг хорошей продуктовой идеи. Следующий порядок роста открыла единая платформа с чёткими ролями, специально построенной плоскостью прямого видео, настоящей консолью администратора и родительским интерфейсом, снявшим половину нагрузки на поддержку. Сами по себе технологии ничем не примечательны; всё решают решения о том, где их применить.

Если ваш бизнес держится на прямых занятиях, видимости для родителей или отлаженных административных процессах и вы перерастаете готовые решения — подход Scholarly (сначала роли, гибридное видео, микросервисы, ранняя наблюдаемость) — это именно то, что мы применили бы к вашему проекту. Консервативный бюджет. Честные сроки. Без показухи.