Design a Course Registration System

## Prompt Design a course registration system with a relational schema and APIs for browsing course offerings, enrolling, dropping, and viewing a student's schedule. Prevent enrollment beyond capacity and conflicting duplicate registrations under concurrent requests. ### Constraints & Assumptions - A course can have several term-specific sections, each with its own capacity. - A student may be enrolled or waitlisted in a section, but not both. - Repeated enrollment requests use an idempotency key. - The first version need not implement prerequisite evaluation or timetable conflicts. ### Clarifying Questions to Ask - Is the waitlist FIFO, priority-based, or manually controlled? - Can instructors override capacity, and must such actions be audited? - What consistency is required between a drop and promotion from the waitlist? ```hint Protect the capacity decision Lock or conditionally update the section capacity record in the same transaction that creates enrollment. ``` ### What a Strong Answer Covers - Normalized entities, keys, uniqueness constraints, and enrollment states. - APIs and transactional logic for enroll, drop, and waitlist promotion. - Concurrency control that proves capacity cannot be oversubscribed. - Idempotency, authorization, validation, and error semantics. - Read scaling, audit events, tests, and operational metrics. ### Follow-up Questions 1. How would you add prerequisite and schedule-conflict checks without creating long lock chains? 2. How would you support a registration opening that creates a sudden traffic spike? 3. How would you repair a waitlist promotion that failed after a drop committed?