Recently, a lot of ideas has been discussed 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 site’s fast growth, from a single small database to a large master configuration in the first weeks, and eventually to the dozens of database servers running. Read more: https://savvycomsoftware.com/whats-new-in-ruby-on-rails-4/
If there’s one thing that has been learned from a scale of RoR, it’s the importance of having an elastic architecture for your application, enabling an immediate response to traffic spikes and occasional failures.
- Read more: top in-demand programming languages 2019
Like most website’s startups, we had our share of downtime and crashes. No framework in the world provides total immunity to mishaps. Looking back at 2012, almost all problems were caused by human errors and not lack of scalability. In fact, most of our downtimes were caused by infrastructure failure and not 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, so many apps which were built without paying enough attention to RoR’s 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.
Finally, whether or not you may choose Ruby on Rails for your next app or site, but make sure you invest significant time planning for Rails’s scalability, specifically when it comes to your databases.