This is the first in a series of posts covering the challenges involved in scaling web apps. I’ll try to share the lessons we’ve learned while scaling Fiverr from zero to one of the top 200 websites in the world!
People often ask me what led us to choose Ruby on Rails back in the day. I hope this will shed some light on that choice which is, in many ways, more trivial today then it was when we started, around mid 2009.
We planned to launch Fiverr quietly, staying under the radar while getting our act together. We were lucky, things did not happen quite as we planned.
March 2010 was a great first month for us, traffic was picking up nicely and users were pouring in. That night, I woke up to an SMS alert sent by one of our monitoring services. It seemed that our realtime analytics counters went crazy – it was showing insane numbers of concurrent users.
Turned out we were covered on Yahoo! that night. The counters were correct.
It took a few minutes before the downtime text landed on my iPhone. All hell was about to break loose if it wasn’t for our little secret weapon – the foundation of a scalable architecture.
Rails has you covered!
A lot has been said about Rails’s lack of scalability. While some of it may be true, it is after all a well structured framework for rapidly creating web applications that can easily support scaling from small to medium, and with reasonable effort, to large-scale as well. In fact, the very use of RoR at the time, enabled us to support Fiverr‘s insanely fast growth, from a single small database to a large master/slave configuration in the first weeks, and eventually to the dozens of database servers running under Fiverr’s hood these days.
If there’s one thing we’ve learned, it’s the importance of having an elastic architecture for your application, enabling immediate response to traffic spikes and occasional failures.
Like most web startups, we had our share of downtime and crashes. No framework in the world provides total immunity to mishaps. Looking back at 2012, most of our problems were caused by human errors and not lack of scalability. In fact, most of our downtimes, were caused by infrastructure failure and not our web application.
One could argue that infrastructure failure should not affect uptime at all if an app is built right. However, as an industry I think we are all paving the way for the next generation to come. One unfortunate example of this would be Amazon’s recent outages which brought down Pinterest and others.
In the past few of years, I’ve come across more than a few apps which were built without paying enough attention to scalability. Some of these apps had to go through massive code rewrites just to throw another database slave to the mix. For some, this meant hours and even days of downtime.
Whether or not you choose Ruby on Rails for your next app, make sure you invest significant time planning for scalability from day one, specifically when it comes to your databases.
The good news is that Rails makes mid-size scalability (millions of visitors per month) achievable. If you’re not going for an Amazon off-the-shelf scaling solution, I suggest you read the following: