Getting Ready: Course Registration

Every semester, millions of students race to register for courses at universities worldwide. Systems like Ellucian Banner, Oracle PeopleSoft, and Workday Student process thousands of concurrent enrollment requests during registration windows that sometimes last only hours. When these systems fail — and they do — students lose access to required courses, graduation timelines slip, and universities face operational chaos.

The Course Registration System is a compelling LLD problem because it combines several distinct engineering challenges into one design. Prerequisite validation requires modeling course dependencies as a Directed Acyclic Graph (DAG) and verifying that a student has completed every course in the dependency chain. Capacity management demands atomic seat allocation — when 200 students target 30 open seats, the system must handle race conditions gracefully. Waitlist management introduces the Observer Pattern: when a student drops a full course, the next waitlisted student must be notified automatically. Schedule conflict detection requires reasoning about time intervals to prevent a student from enrolling in overlapping sections.

Interviewers favor this problem because it naturally exercises graph algorithms, behavioral design patterns, and multi-entity coordination. A strong solution demonstrates comfort with DAG traversal, the Observer and Strategy patterns, and careful capacity handling — skills that transfer directly to inventory systems, booking platforms, and resource schedulers.

By the end of this design problem, you will be able to:

• Model prerequisite dependencies as a DAG — represent course prerequisites as directed edges and validate them using topological reasoning (no cycles, all ancestors satisfied)
• Apply the Observer Pattern to manage waitlists — when a seat opens, automatically notify the next student in line without coupling the enrollment logic to the notification mechanism
• Apply the Strategy Pattern for enrollment rules — swap between first-come-first-served, priority-based (seniors first), and lottery-based enrollment without modifying the registration service
• Design a UML class diagram with 12+ classes spanning students, courses, sections, enrollments, schedules, and the prerequisite graph
• Design a UML sequence diagram tracing the full registration flow — from prerequisite check through capacity validation, enrollment, and waitlist fallback
• Handle schedule conflicts by comparing time intervals to prevent overlapping enrollments
• Enforce credit hour limits to cap the number of courses a student can take per semester

Before starting this problem, make sure you're comfortable with:

• OOP Relationships — especially Composition, Aggregation, and Association. You'll need to decide whether a Section composes within a Course or merely associates with it (Fundamentals S4)
• Observer Pattern — how one object notifies many dependents when its state changes. The waitlist system is a textbook Observer application (Fundamentals S12)
• Strategy Pattern — how to encapsulate interchangeable algorithms behind a common interface. Enrollment rules swap at runtime (Fundamentals S12)
• UML Class & Sequence Diagrams — reading and constructing both diagram types (Fundamentals S5)
• Graph Basics — understanding of directed graphs, DAGs, and cycle detection. If you're unfamiliar, a quick review of topological sort will help with the prerequisite validation tutorial

We will design:

• Course catalog with sections, schedules, and instructors
• Student enrollment and drop workflows
• Prerequisite dependency graph (DAG) and validation algorithm
• Capacity-limited sections with waitlist management
• Schedule conflict detection for overlapping time slots
• Credit hour limit enforcement per semester
• Observer-based waitlist notifications
• Strategy-based enrollment rules (first-come-first-served, priority, lottery)

We will NOT design:

• Database schemas, persistence layers, or ORM mappings — this is an object-oriented design exercise
• REST APIs, HTTP endpoints, or frontend interfaces
• Payment or billing systems for tuition
• Grade management, GPA calculation, or transcript generation
• Instructor workload management or room scheduling
• Distributed systems, load balancing, or horizontal scaling
• Authentication, authorization, or role-based access control