How we created the best online voting test
… and amazed ourselves
When the University of Antwerp in participation with Treecompany asked Wieni to develop the “Stemtest” (political online voting test) we instantly knew we didn’t want to build this in Drupal, like we do for most of our sites. At that time, we were experimenting with Backbone.js. This new project seemed like the perfect opportunity to gain some hands-on experience . We had to expect about six million submissions in one month, with peaks up to 15.000 users at the same time. This meant that we had to reevaluate the way we store data, and determine if we could minimize its retrieval or even avoid it altogether.
What is this test?
The “Stemtest” is an online test made for Belgian citizens to find out with which political party they share the most common ground by answering around 36 questions. This year we covered the European, national and regional elections. The latter consisting of the Flemish, Walloon and Brussels-capital region. Each of these regions were assigned a different set of questions which in turn were related to different political parties. To make matters worse it had to be implemented for different key partners, like the national radio, television and some national papers from the Flemish and Walloon region. You had 3 options to choose from when you were answering the questions: agree, disagree and no opinion (with a certain limit for the latter).
Make everybody happy
Gulp for president
The University of Antwerp wanted to store all the answers (anonymously) for research purposes. As you can see in an early schematic above, we did send all the data to a simple PHP script which in turn saved it in a table (one for each test/version). When a user altered his initial answer we concatenated any subsequent answers to the initial answer-string for that specific question. We didn’t want to wait for a response from the server. This had a nice upside: if the backend went down, nobody would notice (it didn’t go down by the way, kudos to Stone Internet Services). (More technical: this opened up the possibility of serving the static application from nginx servers which would remain unaffected by any load on the PHP script).
As stated earlier, we were trying to minimize any server-side load. Retrieving the raw user input from the server and recalculating the scores seemed overkill for a shared result page. Therefore we embedded the result into the share url.
The part after ‘resultaat’ (result) was a complicated obfuscation of your results. For example party 1: 10%, party 2: 34%, etcetera … No backend needed, neat!
Be prepared for everything
The biggest advantage of not using any server side code for the tests was of course the load Stone could handle with their CDN. Stone did an extensive load test to monitor everything in advance. When the national television did a piece about it in prime time we had our first real peak (damn what a night). Stone sent us an email: “they didn’t have any CPU load above 4%-5%”.
On a final note: be creative, from the start we did anticipate a huge load, so we designed everything around this. In the end, we did succeed, this is one of our best projects we did this year.
ps: some versions of Safari 6 don’t sort the object properties like Chrome V8 sorts them (according to the order they were inserted), We learned this the hard way.