Every year tens of thousands of spectators line the streets of Brighton and Hove to cheer on the runners. When people are out and about on the streets they want an easy way to find out how their friends and family are doing, where to look out for them and what time they are likely to be nearby.
A mobile app is ideally suited to this - it makes use of location-specific data and as a spectator you will have your phone with you on the day.
Each runner has a small tag (RFID) attached to their shoes. As they cross the start, 10k, half way, 30k and finish points they run over mats and the tags are detected. We work with the timing company, HS Sports, who record this and send the timings to us. We publish this data to the app as it happens, so as a spectator you can have this information on your phone within in just a few minutes of it happening. T
his year we introduced an Android app in addition to the iPhone app. It was also the first time timing data was available from five different locations along the course.
This year’s apps were downloaded over 24,000 times between them and the iPhone app peaked at number 24 on the iTunes list of free apps.
A record 9300 people ran the 2013 Brighton Marathon.
86% of them were followed by at least one user of the app.
I'll briefly mention a couple of technical aspects which were essential to the smooth running of the day:
A well structured relational database.
Most of the querying is done with SQL, and PostgreSQL is our preferred choice for this, thanks to its robustness, strong type checking, XML support, array types and aggregation functions. For this application we’ve pushed much more logic into the database.
There are good arguments for and against this, but it’s worked well here. Many queries now return XML documents containing complete data structures, making our application server code quite trivial, effectively mapping one HTTP request to one SQL query. The next PostgreSQL release will have similar JSON support too, which will increase its usefulness for these sort of queries.
A well designed REST interface.
We’ve also worked hard to get an API that’s clean and adheres to REST principles. The apps now do a lot more of the work themselves with regard to calculating estimated locations and collating your friends’ results. They get all the data they need from well-defined URLs.
There’s an excellent talk on designing HTTP interfaces from DrupalCon 2012 which helps with this (it’s not specific to Drupal). All this makes scaling up this sort of application much easier.
We faced a number of challenges on the race day:
Handling 10 million+ hits on a single day
We use the nginx web server because it’s very, very good at serving cached content, and we made as many of the requests work with this as possible in order to reduce the load on the database.The rest are delegated to an Apache and PHP backend. Cloud hosting is ideal because it lets us rent huge capacity for a few days around the event and reduce it for the rest of the year, only paying for what we use.
Availability of the phone networks
With so many people packed into Brighton city centre, and the increasing number of them with smartphones, it’s often difficult to get good internet access. While the results website works very well on a mobile phone, you do need to be online in order to navigate it. Native apps provide a richer interface, so it’s possible to navigate it even if your phone doesn’t have connectivity right at that moment.
The app starts checking and downloading data for your friends as soon as it is launched, with the aim of having it before you want to view it, or at least as soon after as possible.
Redundancy
An event like a marathon is so time-critical that even a short period of downtime can ruin the user experience. To mitigate this we have two independent servers available to receive timings and serve data. These are with two different hosting providers (Bytemark and Amazon). If we have a problem with either one on the day, we recognise there isn’t time to fix it and can just swap them over.
We actually did this as a precautionary measure this year when one of the servers showed some warning signs. The apps and results website were well received and we got a lot of good feedback. During the day we monitored social media for mentions of the app. That’s enabled us to come up with some useful improvements for next year that will help runners and spectators get even more out of the app.
I’m looking forward to future marathons!
This article was originally written for Brightec by Erik Erskine
Search over 400 blog posts from our team
Subscribe to our monthly digest of blogs to stay in the loop and come with us on our journey to make things better!
We develop intelligent mobile apps for iPhone & Android that deliver for you.
Want to connect? You can find us on Instagram, Facebook, X (formerly Twitter) and LinkedIn.
Here’s our privacy policy.
Here’s our Accessibility statement.
Copyright © 2024 Brightec Limited. All rights reserved.
