Tinder swipes right for database-as-a-service from Rackspace
- Summary:
- Dating app has met its match in Rackspace’s ObjectRocket hosted MongoDB service.
That’s the simple principle that drives Tinder, the flirting/dating/hook-up app that asks you to check out photos of possible love/lust interests and pass judgement on them.
If you like them by swiping right, and they ‘like’ you right back, then bingo - you’ve made a match and the two of you can start messaging each other. It’s said by fans to be powerfully addictive, precisely because of its simplicity.
But, behind the scenes, a huge amount of database activity powers the service, according to Tinder’s chief technology officer, Ryan Ogle.
Tinder users perform a collective 1.7 billion swipes per day, creating 25 million matches in the process. Each and every swipe must be logged in order for the service to work properly, he says:
If you perform a right swipe, we’re checking to see if that user’s right-swiped you. If they haven’t, your swipe is logged as a pending match. If you pass on someone, we don’t create a match and that person is taken out of your queue.
So that’s a huge challenge: it’s important for Tinder we never show you the same person twice. And we need to deal with huge volumes of data, making sure the system’s highly available and offering rapid response times.
Tinder users, it seems, are a pretty impatient bunch. Says Ogle:
One thing we discovered early on is that the speed it takes to serve a request is directly proportional to how engaged a user’s going to be. We saw that, when we had an issue - when the recommendation engine or ratings system was running slow - you’d see engagement totally fall off. And the moment you broke through the barriers and fixed the problem, you’d see massive amounts of re-engagement.
Tech structure
From the start, Tinder has used the MongoDB NoSQL open source database to support its service - for some time as an in-house implementation and also with several third-party providers. After some less-than-satisfactory experiences, Tinder signed up for Rackspace’s ObjectRocket MongoDB managed service in May last year.
So why MongoDB and why Rackspace? Ogle says:
That said, there is some disagreement in the developer community around MongoDB, with one criticism being that it favours speed over consistency. It’s a point that Ogle acknowledges.One of the great things about MongoDB is that it’s very easy to prototype against - and that’s important when you’re growing a service. So we don’t need to do a lot of planning around schemas. We don’t need to do a lot of the work around creating different tables or introducing joins that you might need to do with a traditional database. The other big advantage that we saw early on is that we didn’t have to do application-side sharding. The horizontal scale we need is handled within Mongo itself. That’s a really big advantage for us.
There are certain things it does that are designed to increase speed. It’ll take, for example, a bunch of writes and hold them in memory and periodically write that information to disk at a more convenient time. So there IS a chance you might lose data, but you get a lot of performance out of it. In our experience, the chance is losing data is very, very, very small - and we’re not running a bank. Having a perfect transactional database isn’t a requirement for us.
Worst case scenario? One user messages another and the message doesn’t go through. That a perfectly acceptable risk, when it’s weighed against the benefits of having a high-performance service. We really like Mongo: its use depends on your type of application and the consistency you need, but it’s a great choice for us.
However, finding and recruiting talented MongoDB database admins (DBAs) is a big challenge, which is why Tinder decided to go down the managed service route, says Ogle:
ObjectRocket has really great, talented DBAs - so we use them and that allows us to focus on what we do best: engineering. Our internal IT team is focussed on DevOps and automation and all the engineering needed to keep building out the service and adding new features and functions.
Since moving to Rackspace ObjectRocket, Tinder has seen a four-fold improvement in performance and stability, he adds.
We carefully measure and test the amount of throughput ObjectRocket can handle. We always want to know more: what happens when we throw X amount more traffic at it? Recently, we experienced a potential problem when one of our caching layers had an issue and died. Every request was firing straight at ObjectRocket and it took the strain of that throughput like a champ, with no downtime at all.
Tinder, it seems, has met its match in Rackspace ObjectRocket. At diginomica, we love a happy ending.