Как 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. Домашние задания — в Google 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 и переписке в почте.

Родители

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

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

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

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

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

1. Масштаб прямого видео. Готовые LMS поддерживают интеграцию с Zoom, Vimeo и YouTube. Однако ни одна из этих платформ изначально не рассчитана на интерактивные лекции для 2000 человек с общей доской в одном потоке.

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 надёжности. Доступность — 99,95% и выше на пути прямого занятия, доля неудачных деплоев — менее 2%, MTTR — менее 30 минут в учебные часы, доля успешных бэкапов — 100%.

Когда не стоит создавать собственную LMS

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

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

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

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

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

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

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

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

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