Election night in a newsroom is what you might imagine: constant motion. Nowhere is this more apparent than in the results that come into our systems and are published out to the newsroom, to nytimes.com and to our mobile site.
To get those updated numbers to readers, we need to connect information supplied by the Associated Press to our own database and publishing systems, and we have to do it in a way that allows us to roll with whatever comes in once the polls close. Oh, and update it every three minutes for hours. Here’s how that happens:
It starts with an FTP service provided by the AP. Depending on which states are holding elections, our scripts pull down delimited text files containing candidates, races and results and insert them into a MySQL database. Turning FTP data into publishable results on the homepage, the Politics section and mobile.nytimes.com requires a lot of tending, and the Ruby on Rails application designed for the job has to serve as the glue that connects all of the pieces.
One important task is putting state and county results in front of Times reporters, editors and producers so they can make judgments on how races are going and when to call the winners. The others are variations of putting the result data in front of readers, from the big-picture view to a detailed examination of a single state’s votes. The graphics desk built county-by-county and margin of victory maps to illustrate where the candidates are doing well, or not well.
All of that, including publishing mobile results, occurs every three minutes throughout the night. In practice, that means that the entire process has to finish well inside that 3-minute window so that readers can get a sense of the changes that are occurring as results come in. For a night like Super Tuesday, when 24 states were voting, that required threading processes rather than waiting for a state’s files to be pulled down from the FTP server before starting another.
Elections tend to produce heavy Web site traffic, too. Super Tuesday was the busiest day in NYTimes.com history — at least until the following day, which saw even more traffic. That was largely because of the coverage of the presidential primaries and caucuses. But more visitors and page views didn’t mean more stress on our election results system. Because the Rails application is publishing out HTML and text files, scaling isn’t much of an issue. It just needs to work quickly.
As Times readers know, election surprises are nothing new: results can be late, or even occasionally in error, and some states finish reporting results long before others. By creating an application that can handle the variations — switching states “on” or “off” as needed, or publishing only four candidates if the others have dropped out but remain on the ballot — we’re able to adjust to whatever comes on election night.
After the presidential primaries are over, we’ll be taking a look at our results application and deciding what we can do better for the November general election. If you have ideas on how you’d like to see election results on nytimes.com, let us know.
Comments are no longer being accepted.