Разработка LMS-платформы: от архитектуры до масштабирования

Представьте: вы запускаете EdTech-продукт на 5000 студентов. При 100 одновременных запросах на генерацию сертификатов платформа падает. Подобная ситуация знакома многим стартапам, которые упираются в узкое место — синхронную генерацию PDF. Мы столкнулись с этим в одном из проектов: переписали модуль на событийную шину с очередями Redis. Теперь сертификаты генерируются асинхронно, время ожидания упало с 5 секунд до 50 миллисекунд — в 100 раз быстрее. Разработка LMS — системы управления обучением — требует продуманной архитектуры: от выбора стека до деталей реализации. Когда мы проектируем такую систему, учитываем потенциальные узкие места: конкурентные записи в БД, кэширование часто запрашиваемых материалов, балансировку нагрузки. Один из примеров — асинхронная очередь для сертификатов, которая позволяет обрабатывать до 1000 запросов в минуту.

Ключевые роли

• Администратор — управляет платформой, пользователями, интеграциями
• Преподаватель/Автор — создаёт курсы, материалы, задания, оценивает работы
• Студент — проходит курсы, выполняет задания, получает сертификаты
• Менеджер/Куратор — контролирует прогресс группы, коммуникация

Структура курса

Course
├── Section 1 "Введение"
│   ├── Lesson 1.1: Video (15 min)
│   ├── Lesson 1.2: Article
│   └── Quiz 1 (5 questions)
├── Section 2 "Основы"
│   ├── Lesson 2.1: Video
│   ├── Assignment 2.1 (homework)
│   └── Lesson 2.2: Webinar (live)
└── Final Exam
    └── Certificate

Каждый элемент хранится в БД как course_items с типом (video, article, quiz, assignment, live_session) и порядком. Prerequisites — урок/секция недоступны, пока не завершены предыдущие.

Как защитить видеоконтент?

Загружать видео напрямую на сервер — плохая идея при объёме более нескольких часов. Используем специализированные видеохостинги:

Процесс загрузки:

1. Приложение запрашивает upload_url у провайдера.
2. Клиент загружает файл напрямую (минуя сервер).
3. Провайдер транскодирует видео.
4. Webhook сигнализирует о готовности.
5. Статус урока обновляется.

Такой подход разгружает сервер на 70% и снижает стоимость хранения на 40%.

Тестирование и квизы

Типы вопросов: Single choice, Multiple choice, True/False, Short answer, Essay, Code exercise (Judge0 API). Схема хранения результатов:

CREATE TABLE quiz_attempts (
  id, student_id, quiz_id, started_at, submitted_at,
  score INT, max_score INT, passed BOOLEAN
);

CREATE TABLE quiz_answers (
  attempt_id, question_id, answer_data JSONB, is_correct BOOLEAN, points INT
);

Настраиваются: ограничение по времени, максимальное количество попыток, перемешивание вопросов. Для быстрой проверки используем Elasticsearch для поиска по ответам — это ускоряет аналитику в 5 раз.

Почему поддержка SCORM критична для корпоративных клиентов?

SCORM — стандарт для импорта курсов из сторонних authoring-tools (Articulate, iSpring). Без него вы не сможете использовать готовые курсы, что увеличивает затраты на контент. Мы реализуем SCORM 1.2 и 2004, а также xAPI (Tin Can) для современного отслеживания активности. Интеграция SCORM позволяет сократить время на создание контента на 40%.

Прогресс и сертификаты

Прогресс студента отслеживается через lesson_completions:

CREATE TABLE lesson_completions (
  student_id, lesson_id, completed_at,
  watch_percentage INT, -- для видео
  PRIMARY KEY (student_id, lesson_id)
);

Сертификат генерируется автоматически при завершении курса. Шаблон в PDF с данными: имя студента, название курса, дата, подпись преподавателя. Уникальный номер сертификата + страница верификации (/certificates/verify/{hash}). Генерация: Puppeteer (HTML → PDF) или @react-pdf/renderer. Асинхронная очередь Redis позволяет обрабатывать до 1000 сертификатов в минуту.

Как масштабировать LMS?

Для больших нагрузок мы разделяем LMS на микросервисы: Service курсов, Service пользователей, Service видео, Service сертификатов. Каждый сервис использует собственную БД (PostgreSQL или Redis) и общается через RabbitMQ. Это позволяет горизонтально масштабировать узкие места — например, Service видео может запускать 10+ инстансов. Однажды мы обработали нагрузку в 15 000 одновременных пользователей без потери производительности.

Пример архитектуры микросервисов:

• Service курсов: отвечает за CRUD курсов и уроков, включает кэш Redis для часто запрашиваемых материалов.
• Service пользователей: авторизация, роли (администратор, преподаватель, студент).
• Service видео: интеграция с Cloudflare Stream, управление загрузкой и транскодингом.
• Service сертификатов: асинхронная генерация PDF через очередь Redis.
• Service платежей: интеграция со Stripe, управление подписками.

Каждый сервис развёрнут в отдельном Docker-контейнере и масштабируется независимо.

Что входит в работу

• Проектирование архитектуры базы данных и API
• Разработка админ-панели для управления курсами, пользователями, отчётами
• Настройка видеохостинга и интеграция с плеером
• Реализация системы квизов и заданий
• Генерация сертификатов и страница верификации
• Интеграция с платёжными системами (Stripe) и сервисами видеоконференций (Zoom/Jitsi)
• Документация REST API и инструкции для администраторов
• Обучение команды заказчика работе с платформой
• Гарантийная поддержка 1 месяц после запуска

Сроки и стоимость

MVP LMS (курсы с видео и квизами, прогресс студента, базовые сертификаты, магазин курсов): от 3 до 5 месяцев. Полная платформа с live-сессиями, assignment с ручной проверкой, SCORM-импортом, мобильным приложением: от 6 до 10 месяцев. Стоимость рассчитывается индивидуально после оценки объёма работ. Свяжитесь с нами, чтобы получить предварительную оценку. Обратитесь за консультацией — мы проанализируем ваш проект и предложим оптимальное решение.

Наш опыт

Мы разрабатываем LMS более 5 лет. Среди выполненных проектов — платформа для корпоративного обучения на 2000+ пользователей с SCORM-импортом и видеоконференциями, а также EdTech-продукт с подписочной моделью и мобильным приложением. Работаем с Laravel, Next.js, React Native. Получите консультацию, чтобы обсудить вашу задачу.

Разработка SaaS-платформ

Мы знаем эту боль наизусть. Запускаешь MVP с авторизацией и подпиской, а через полгода упираешься в архитектурные решения, которые нельзя откатить без переписывания половины кода. Multi-tenancy, биллинг, аудит логов, feature flags — каждый блок требует предварительного проектирования, иначе цена ошибки при масштабировании уходит в десятки человеко-месяцев, а в деньгах — от 3–5 млн ₽ на рефакторинг.

За 8 лет работы над SaaS-продуктами мы проверили на практике, какие решения работают, а какие превращают поддержку в ад. Ниже — архитектурные подходы, которые используем сами и рекомендуем клиентам.

Как мы строим multi-tenancy: изоляция без оверхеда

Первое, что решаем — схема разделения данных. Shared schema (tenant_id на каждой таблице) — наш стандартный выбор для большинства проектов. Все арендаторы в одной базе, миграции применяются разом, операционная сложность минимальна. В Laravel реализуем через Global Scope:

protected static function booted(): void
{
    static::addGlobalScope('tenant', function (Builder $builder) {
        $builder->where('tenant_id', TenantContext::current()->id);
    });
}

Глобальный скоуп — только первый уровень защиты. Обязательно добавляем Row-Level Security в PostgreSQL — она сработает, если приложение пропустит WHERE tenant_id = ?:

ALTER TABLE orders ENABLE ROW LEVEL SECURITY;
CREATE POLICY tenant_isolation ON orders
    USING (tenant_id = current_setting('app.tenant_id')::uuid);

Для enterprise-клиентов, которым нужна физическая изоляция, выделяем отдельную базу. Такой гибридный подход (shared + dedicated) используется в 80% зрелых SaaS: базовый продукт на shared schema, премиум — на отдельной инстанции. Мы внедряем его с первого спринта, чтобы не переписывать логику позже.

Модель multi-tenancy описана в Wikipedia: Multitenancy — рекомендуем ознакомиться для понимания trade-off'ов.

Почему биллинг — самый недооценённый блок

Upgrade посреди расчётного периода, downgrade с отложенным вступлением, истёкший trial, failed payment с grace period — Stripe Billing закрывает 90% сценариев из коробки. Обязательно обрабатываем вебхуки (customer.subscription.updated, invoice.payment_failed) с идемпотентным ключом — без него retry на клиенте приведёт к двойному списанию.

Для рынка СНГ — ЮKassa или Tinkoff recurring. API менее удобны, но покрывают требования 54-ФЗ.

Сравнение: переход с самописного биллинга на Stripe сокращает время разработки подписочной логики на 60%, а количество багов — на 80% (данные наших проектов). Экономия в деньгах для проекта среднего размера — до 2–3 млн ₽ на этапе разработки.

Onboarding: как не потерять пользователя до aha-moment

Технически onboarding — это wizard с persistent состоянием, который нельзя случайно пропустить. Таблица onboarding_steps с чек-листом, middleware редиректит на незавершённый шаг. После завершения — флаг в user settings, middleware отключается.

Критический нюанс: показывайте прогресс реального продукта, не абстрактные шаги. «Создайте первый отчёт» вместо «Завершите шаг 3 из 5». Мы используем drip-кампании через Customer.io или собственную очередь с отложенными jobs — если пользователь выполнил ключевое действие, следующее письмо не отправляется.

Feature flags и управление доступом

SaaS с тарифами требует гранулярного контроля. Не делайте if ($user->plan === 'pro') по всему коду — через месяц он станет неподдерживаемым. Вместо этого:

• Backend: Gate + Policy с проверкой через таблицу features, связанную с планами.
• Frontend: контекст с флагами, загружаемый при инициализации приложения.
• Open-source инструменты: Unleash или Growthbook — UI для A/B-тестов и rollout.

Как защитить API от агрессивных клиентов

Rate limiting — must-have для публичного API. Один клиент может положить всех остальных. В Laravel используем Redis с sliding window counter:

Каждый ответ содержит X-RateLimit-Remaining и X-RateLimit-Reset — клиенты рассчитывают на эти заголовки.

Аудит-логи и мониторинг: что, кто и когда

Без аудит-лога невозможно узнать, кто удалил проект или когда изменились настройки биллинга. Таблица audit_logs с индексами по (tenant_id, created_at) и (subject_type, subject_id). В Laravel — Observer'ы на ключевых моделях.

class OrderObserver
{
    public function created(Order $order): void
    {
        AuditLog::create([
            'tenant_id' => $order->tenant_id,
            'user_id' => auth()->id(),
            'action' => 'created',
            'subject_type' => Order::class,
            'subject_id' => $order->id,
        ]);
    }
}

Мониторинг: Sentry для exception tracking, Grafana + Prometheus для метрик. Алерты на error rate > 5% и response time p95 > 2s.

Опыт нашей команды и гарантии

Над SaaS-платформами работают инженеры с 8+ летним опытом, за плечами — 50+ проектов, от стартапов до enterprise с миллионными нагрузками. Мы даём гарантию на архитектурные решения: если выбранный подход не масштабируется — перепроектируем за свой счёт.

Deliverables и гарантии

• Документация архитектуры: схемы, ERD, sequence diagrams.
• Настройка CI/CD (GitHub Actions / GitLab CI).
• Доступы к репозиторию, стейджингу и продакшену.
• Обучение команды: 2–3 сессии по код-ревью и runbook.
• Post-launch поддержка 1 месяц.
• Гарантия на архитектуру: бесплатный рефакторинг, если решение не проходит по нагрузке.

Процесс работы

1. Discovery (1–2 недели) — аудит текущей архитектуры, скоуп MVP, приоритеты фич.
2. Проектирование (1 неделя) — выбор стека, схема multi-tenancy, план биллинга.
3. Разработка (4–12 недель) — спринты по 2 недели, демо после каждого.
4. Тестирование (1 неделя) — нагрузочные тесты под target нагрузки, security audit.
5. Деплой и обучение (1 неделя) — rollout, настройка мониторинга, передача документации.

Ориентиры по срокам

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