Designing a Scheduling Engine for Peak Enrollment

Context

During enrollment windows, thousands of students compete for a fixed number of seats in each class section. Optimistic concurrency alone produced a stream of retries and, occasionally, overbooking when retries raced.

Constraints

• Seat capacity is a hard invariant — never exceed it.
• Confirmation must feel instant to the student.
• The system must sustain bursty traffic during short windows.

Approach

I moved the capacity decision behind a single-writer handler per section. Requests enqueue a ReserveSeat command; a Wolverine handler processes them serially per section key, making the invariant trivial to enforce.

public async Task Handle(ReserveSeat cmd, ISectionRepository repo)
{
    var section = await repo.LoadAsync(cmd.SectionId);
    section.Reserve(); // throws when full — no race possible
    await repo.SaveAsync(section);
}

A Redis-backed availability cache serves read traffic so the dashboards stay fast without touching the write path.

Results

Across three enrollment cycles there were zero overbooking incidents, p95 confirmation stayed under 500ms, and the system handled peak bursts comfortably.

Lessons Learned

Serializing just the contended decision — rather than the whole request — kept correctness simple while preserving throughput everywhere else.