Moving to MongoHQ

Bugrocket launched just over 3 months ago and things have been progressing well. Well enough that it was time for us to take a look at our server infrastructure with a more critical eye.

Until now our setup looked like this:

Clearly this wasn’t a long-term solution.

Gaining confidence that people actually need Bugrocket we started to plan a more robust, long term setup:

  • First, multiple web nodes. Having a single instance is just plain wrong – deploys took down the whole site and heavy traffic makes all your users angry and causes conversions to plummet.
  • Second and most important, even though we had a replica of the database, we aren’t system administrators. It’s not in our blood to manage the details required to get peace of mind and real performance from a database, especially one as young as MongoDB.

We solved the first problem like anyone would, simply adding more web nodes. It’s the database part that was an issue.

Enter MongoHQ (YC11) – a ‘database as a service’ startup running on EC2. We discussed our needs with the (very helpful) Jason McCay and made the (entirely trivial) changes to our app. Then, after doing a bunch of testing and experimentation in dev and staging (making sure things were smooth and behaved as we expected), we were ready. Everything went great.

Services like MongoHQ are becoming more and more common and we think that’s awesome. A database like MongoDB can sometimes feel like a liability when you have little confidence in your production environment. What if our primary DB node goes down? Completely dies? Do we really know how well the recovery plan will work? Losing customer data is simply not acceptable, so outsourcing to people who’s job is just database administration is really appealing.

So, our new infrastucture now looks like this:

…and we’re ready for the next leg of Bugrocket’s trip.