Design a Course Registration System
CitadelSoftware Engineer · Onsite
Last updated
Design a course registration system with relational models and APIs for enrollment, dropping, schedules, waitlists, and course browsing. The solution explains transactional capacity protection, idempotent retries, re-enrollment without duplicate rows, FIFO promotion, outbox notifications, and tests for final-seat races.
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?
Hints
Hint 1
Protect the capacity decision: Lock or conditionally update the section capacity record in the same transaction that creates enrollment.
Follow-up questions
- How would you add prerequisite and schedule-conflict checks without creating long lock chains?
- How would you support a registration opening that creates a sudden traffic spike?
- How would you repair a waitlist promotion that failed after a drop committed?
Solution walkthrough is for members
Get the full walkthrough with reference code and complexity analysis, plus Kitty Coach at 300 messages a day. Hints, the code runner and community answers stay free.