Many of the largest and most sophisticated companies in the world rely on MongoDB, including over a third of the Fortune 100. In addition to well established businesses using the modern database, innovative start ups from around the world put MongoDB at the heart of their data strategy.
This blog series highlights three UK-based start ups transforming their industries with MongoDB. First up, DICE.
Why are we charged booking fees when we buy a ticket to see our favorite band? Years ago, there was a reason. Companies had to manually process orders, print and mail out tickets to fans - which involved a cost. Today, we carry around powerful devices everywhere we go and booking is simply a few swipes, a click and then the ticket is delivered directly to your phone.
Booking fees are dinosaurs, and DICE wants to be the meteor that wipes them out. The guardian described it as: “DICE aims to take tickets out of the hands of touts and put them into the phones of fans.”
However, it’s much more than that at DICE. We’re building applications that have Wembley Stadium scale and to do it, we’re relying on MongoDB.
Best Gigs, No Booking Fees, But lots of data
Built entirely on MongoDB, DICE went live on September 19th 2014 and we launched big. Users had access to big shows such as Jack White at 02 Arena and Red Bull Culture Clash at Earls Court Arena as well as lots of amazing smaller shows featuring brilliant bands.
However, building a robust application that scales up to massive peaks of activity as ticket sales go online requires a lot of backend engineering.
We’ve all been there, sitting at a laptop at 9am, trying to refresh and pulling our hair out because we don’t know if we’ve actually got the tickets we just bought. It turns out building a ticketing application that can have high performance with thousands of operations a second isn’t all that easy. But we had a mission.
How to Sell Out Wembley Stadium - In A Minute
When I joined DICE that was the challenge I was tasked with - how can we sell a million tickets and have the application work seamlessly, while providing a consistent view of ticket inventory. In all of my previous roles, whenever I needed a database with great performance, I went with MongoDB.
Once we did some initial testing and the DICE team saw how intuitive MongoDB was to develop on and how well it performed, MongoDB was an obvious decision. It quickly became a key part of our data strategy and therefore our business plan.
Some of the capabilities that come baked into MongoDB have been vital to our success. For instance, if we need to sell 90,000 tickets for an event, we have to be absolutely sure we don’t end up selling 90,001 or 90,100. Which is kind of obvious, but when bottlenecks start and maybe 150 people are all buying the same ticket at the same time, it’s actually a tricky problem to solve.
We implemented a managed object pool within MongoDB, that creates all the tickets beforehand taking advantage of MongoDB ACID compliant operations. This ensures that each customer gets a unique ticket for the event. That’s our take on concurrency.
Using that system, we know we can sell 90,000 tickets a minute, with the site still performing comfortably. That’s basically Wembley Stadium, every minute, and we know exactly where to push to get those numbers even higher. The reason we can do that is because we have a database that is rock solid at scale.
Our headquarters are currently in London and we are rolling out to more UK cities, before taking on Europe and North America. Selecting a database that can scale as our business grows is essential.
As with many start ups, expanding quickly is a key metric - we need users and we need lots of them. Geographic growth is good, but it also can add complexity for our data. MongoDB is well placed to help address that.
If we’re selling tickets to an LA concert, we need to ensure that the customer has the same excellent experience as a customer in the UK or in Europe. To do this, we have to distribute data to local servers that are physically near to our customers. To make this run smoothly we’ll use MongoDB’s location-aware sharding, to ensure that if someone is in LA, they will be routed to a local server which eliminates the effects of cross-continent geographic latency.
As we expand, we know we need to offer a great service to customers and our partners. Crucially we have to also present a robust plan to potential investors. Having MongoDB at the heart of our application strategy means we’re in a place where we feel very good about scaling this wonderful, crazy idea - best gigs, no booking fees.
Also, we’re looking for all sorts of people to join our team, in particular a MongoDB database administrator.
To see how organizations around the world are building applications never before possible, read our white paper on quantifying business advantage: