Inspiration
The UW uses a service called MyPlan to handle class scheduling.
For eight* days per quarter, at exactly 6 AM, thousands of students each try to be the first to register for classes, so they all try to access MyPlan at the same time. It crashes. For the next few hours, MyPlan is unreliable. An average student refreshes the page for an hour, trying to get into the service so they can register quickly and get an extra hour of sleep before their first class.
*The UW already segments registration based on your credit standing (freshman through senior) and the last digit of your student ID number (0-4, 5-9).
I don't like any part of that process.
The problems
Server downtime is clearly a problem. In a perfect world, a service is never down when a user wants to access it. MyPlan is down when users need to access it most.
As a result of the service being unreliable for over an hour, and made worse by the UW being a strong computer science school, some students automate the registration process. There exists a GitHub repository for a program that will constantly try to register a UW student for classes. This is not allowed by UW policy, but there is no way to differentiate between a human registering and a bot.
When students do get in, they often find that the classes they want to take are filled by "reservers," upperclassmen who help their friends by stealing seats. Later, the reserver will unregister for the class at the same time the friend registers, and the seat is transferred with no contest. This is blatant abuse, but is also not punishable.
Even the timing is an issue. Registration occurs on weekdays, and students often miss out on events the night before registration because they have to wake up at 6, which is hours earlier than their normal routines. Lectures are disrupted both because the students are tired and because they're constantly changing their registration plans around filled classes.
The proposal
Instead of making registration into a race, MyPlan should make registration a game of chance.
Class scheduling is available for months before the registration start date. Currently, almost all students build their schedules during this time, and all they need to do at 6 AM is submit it to the registration database.
The proposal removes the need to manually submit on registration day by allowing students to submit their schedules anytime. However, the registration system does not accept the schedule into the master database at this time. Instead, it sends it to an intermediate database corresponding to the student's credit standing.
On each of four days, the intermediate database with the corresponding credit standing tries to "dump" to the master database at, say, 3 AM. Students are ordered pseudorandomly, such as with a salted hash of their id. If a student wants to register for a class that has seats available, the registration proceeds. Otherwise, the rest of that student's classes are attempted as normal and the student would receive an email about the conflict. Seniors who had conflicts are then able to try again during the juniors' registration dump. There are still no races: Changes are accumulated through the day and are only finalized at 3.
The proposal fixes the problem of server overload since there is no longer a time at which everyone tries to access the system. It fixes the problem of robot registration by removing the benefit of using a bot, namely speed. It saves students from having to update their schedules in lecture since updating after lecture will give the same result. Students won't be tired during lecture because they won't have to wake up at 6. It even alleviates the problems with reservers by removing the guarantee that a spot released by a reserver will be taken by their friend.
How I built it
The code provided is an example of how a registration dump would work.
I used Ruby because it's a comfortable prototyping language for me, and it's not known for its speed. If an application runs in Ruby, it'll run in any language. I use the libraries Sequel and Sinatra for database operation and web hosting respectively.
What I learned
I already knew how all the tools I used work. What I'm learning is that a good idea doesn't go anywhere if nobody notices it. That means I need a good sales pitch.
What's next for Fix the MyPlan Overloads
Without knowing what the inside of the registration system looks like, I can't necessarily generate ideas that will work with the system. I would like to be able to talk with UW IT to see if this proposal is even realistic to implement. If so, I'd want to work with them on it. If not, knowing more about what can and can't be done will give me some direction.
Log in or sign up for Devpost to join the conversation.