Design a Learning Management System

The Problem

Your ed-tech startup serves 50,000 students across 800 courses. The current system stores all content in a flat lessons table with a course_id foreign key, and every time a student opens a course page the backend recalculates their completion percentage by scanning every row. Last week an instructor rearranged the modules in a popular Python course, and 3,000 students lost their progress because the ordering was derived from database row IDs. A week before that, the quiz engine let a student submit answers to a quiz they had never unlocked, bumping their completion to 100% and generating a fraudulent certificate.

Learning platforms combine content management with a progression system. Courses have internal structure (modules, lessons, quizzes), students move through that structure at their own pace, and the system must track where each student stands. Get the progression logic wrong and students either skip material they need or get stuck on material they have already completed. Get the quiz engine wrong and certificates become meaningless.

Design the core classes for a learning management system that handles course creation with modules and lessons, student enrollment, sequential lesson unlocking, progress tracking, a quiz engine with multiple question types, and certificate generation upon course completion.

Requirements

Clarifying Questions

Before jumping into class design, ask questions to turn the vague prompt into a concrete specification. Cover four areas: core actions, error handling, boundaries, and future extensions.

You: "What does the course structure look like? Is it a flat list of lessons or a nested hierarchy?"

Interviewer: "A course contains ordered modules, and each module contains ordered lessons. Students must complete lessons in sequence within a module, and modules unlock in order."

Two levels of nesting: Course → Module → Lesson. Sequential unlock at both levels. That means we need explicit ordering on both modules and lessons, not just database insertion order.

You: "What types of lessons are there? Just video, or text and quizzes too?"

Interviewer: "Three types: video lessons, text lessons, and quiz lessons. Video and text lessons are marked complete when the student finishes them. Quiz lessons require a passing score."

Three distinct lesson types with different completion criteria. This is a strong signal for polymorphism or a strategy pattern: the completion check varies by lesson type.

You: "How does the quiz engine work? What question types do we need?"

Interviewer: "Support multiple choice, true/false, and free-text questions. Each quiz has a passing threshold as a percentage. The system auto-grades multiple choice and true/false. Free-text is graded by keyword matching for now."

Three question types with different grading logic. Another clear polymorphism signal. The passing threshold lives on the quiz, not on individual questions.

You: "What should happen if a student tries to access a lesson they haven't unlocked?"

Interviewer: "Reject the attempt. Students must complete the previous lesson before accessing the next one. Same for modules: all lessons in module N must be complete before module N+1 unlocks."

Strict sequential access. We need a method that checks whether a given lesson is accessible for a given student. This is the core progression logic.

You: "When does a student earn a certificate? Can they retake quizzes?"

Interviewer: "A certificate is generated when every lesson in every module is marked complete. Students can retake quizzes unlimited times. Only the latest attempt counts."

Certificate on full completion. Quiz retakes mean we store the latest attempt, not a history. That simplifies the data model considerably.

You: "Do courses have prerequisites? Can a student enroll in any course?"

Interviewer: "Yes, courses can have prerequisite courses. A student must have completed all prerequisites before enrolling. Some courses have no prerequisites."

Course-level prerequisites add a dependency graph. We need to check completion status of prerequisite courses before allowing enrollment.

You: "Should we handle instructor dashboards, ratings, refunds, or downloadable content?"

Interviewer: "Those are extensions. Focus on the core: course structure, enrollment, progress tracking, quizzes, and certificates. We can discuss instructor analytics and ratings as follow-ups."

Good. You have scoped out ratings, refunds, downloads, and instructor dashboards. The core is tight: structure, enrollment, progress, quizzes, certificates.

Final Requirements

Functional Requirements:

1. Instructors create courses with ordered modules, each containing ordered lessons (video, text, or quiz)
2. Students enroll in courses after completing all prerequisite courses
3. Lessons unlock sequentially within a module; modules unlock sequentially within a course
4. Progress is tracked per lesson, per module (percentage), and per course (percentage)
5. Quiz lessons contain multiple question types (MCQ, true/false, free-text) with auto-grading
6. Quizzes require a configurable passing score; students can retake unlimited times
7. A certificate is generated when a student completes all lessons in all modules of a course

Non-Functional Requirements:

1. Extensible for new lesson types without modifying existing code
2. Extensible for new question types without modifying the quiz engine
3. Thread-safe enrollment and progress updates

Out of Scope:

• Instructor dashboards and analytics
• Course ratings and reviews
• Payment processing and refunds
• Downloadable content and attachments
• Live sessions and real-time collaboration

Example Inputs and Outputs

Scenario 1: Student enrolls and completes a lesson

• Input: Student "Alice" enrolls in "Java Fundamentals" (no prerequisites). She opens Module 1, Lesson 1 (a text lesson) and marks it complete.
• Expected: Enrollment created. Lesson 1 marked complete. Module 1 progress = 1/4 (25%). Course progress = 1/12 (8%). Lesson 2 in Module 1 is now unlocked.
• Why: Validates enrollment, lesson completion, progress calculation, and sequential unlock.

Scenario 2: Student attempts a quiz lesson

• Input: Alice reaches Module 1, Lesson 3 (a quiz lesson with passing threshold 70%). She answers 2 out of 3 questions correctly (67%).
• Expected: Quiz scored at 67%. Lesson NOT marked complete (below threshold). Alice can retake. Progress unchanged.
• Why: Validates quiz grading, pass/fail logic, and retake behavior.

Scenario 3: Student earns a certificate

• Input: Alice completes all 12 lessons across 3 modules in "Java Fundamentals," including passing all quizzes.
• Expected: Course progress = 100%. Certificate generated with Alice's name, course title, completion date, and a unique certificate ID.
• Why: Validates full completion detection and certificate generation.

Try It Yourself

---

Step 1: Identify Core Entities

Start by asking: what are the main "things" in this system? Look for nouns in your requirements. Each noun that has its own lifecycle or responsibilities becomes a candidate class.

A common mistake is merging Course and Enrollment into one class, or embedding progress data directly into Lesson objects. The course structure is shared across all students; progress is per-student. Mixing them means every student sees every other student's progress, or worse, you end up copying the entire course structure per enrollment.

Notice that Course, Module, and Lesson form the content hierarchy (shared, immutable during a student's session), while Enrollment and Progress form the student-specific tracking layer. Separating these two concerns is the single most important design decision in this problem.

Step 2: Define Relationships and Class Design

Now let's map out how these entities connect and derive their interfaces from the requirements.

Enrollment: The Central Orchestrator

The Enrollment class does the heavy lifting. It links a student to a course and owns all progression logic. Let's derive its interface from the requirements.

Deriving state from requirements:

Deriving methods from needs: