How Untappd Reduced App Response Times with

[This post is part of a series of customer success stories that Chad Arimura is putting together highlighting key customers and how they are using to do some pretty big things.]

blankUntappd is a mobile location based service for beer lovers that allows users to log, rate and discover new beers, venues and people. By tracking your history and beer ratings, Untappd can recommend beers that are similar based on your taste profile. You can also see what your friends are drinking all over the world as well as find new beers and locations near you!

I recently spoke with Greg Avola, CTO and co-founder of Untappd. Greg is a coder at heart and has a special love for building fast scalable web applications. This is his story... help beer drinkers celebrate their passions around the world.

What problem did Untappd face before Iron?

Untappd is a check-in service, so we have a lot of background processing that needs to be performed on every single check-in. We were doing all this while a user was checking in, which ended up increasing the time it would take for a user to check-in. This became a huge problem as we started to grow. We needed a scaleable way to deploy our tasks to run asynchronously without the user waiting for these jobs to be completed. These tasks became even more important to us as our content feed became more dependent upon these tasks. Our activity feed was suffering as users couldn't see their checkins as quickly, due to the high response times of their check-ins.

Where did previous solutions fall short?

The obvious choice was to use a message queue system that hooked into our own worker system, however with our small development team, managing and deploying these job become a big burden. It also became clear that we needed to create a scalable architecture - but unclear as to how our small team could manage this. We wanted to focus on building the best product, not building a message queue system that was written in our application's language.

Enter on Rackspace

We currently use Rackspace to host our application and IronMQ / IronWorker exclusively for all our message queues needs. Since IronWorker provides the flexibility of being able to create "jobs" in our our language (PHP), it made writing and deploying workers very easy. In addition - IronWorker is built on a highly scalable infrastructure which means we don't have to worry about the service being able to handle our massive amount of tasks. We currently have around 15 different workers that run through the site and perform calculations and database writes based on when a user checks in.


Using has helped us focus on building a great social platform without having a worry about managing our queues and workers at scale. We've decreased our apps response time by offloading many heavy operations into asynchronous IronWorker tasks instead of waiting for the response to complete. We've also been able to improve our queries, due to the ability to offload insertion to the workers to make the checkin process as fast as possible for our users. If the users can check-in faster, that makes them happy, which makes us happy.

We couldn't have said it better ourselves!  Cheers!

To eliminate the burden of setting up and managing your own queuing and worker system, sign up for a free account today.

And to start getting beer recommendations now, check out

Leave a Comment

This site uses Akismet to reduce spam. Learn how your comment data is processed.