Navigation
Home > Services > Ruby on Rails Hosting > System Architecture
System Architecture
The above diagram is an example of the system architecture we use to deploy Rails applications. We use Apache 2.2 with mod_proxy_balancer on the front end to serve static content and balance the rails application servers behind it. The application servers themselves are Rails applications running in mongrel, a fast HTTP server library for Ruby which is ideally suited to running a rails application as a cluster of instances. All of the dynamic application data is stored in a MySQL database.
Scalability
We designed our system architecture this way because it is inherently scalable. With a small web application, all these components can be running on a single server -- in fact, you can have several web applications running on a single server for very small volume sites. As the application grows, we can trivially rearrange parts of the system, moving them onto separate servers. You could wind up with 5 servers running Apache, 15 application servers running the Rails parts and a few servers running the MySQL cluster at the back end!
So long as the web application has been written with scalability in mind (and all of ours are!), it's trivial to rearrange things as usage dictates. In fact, it could be as simple as changing a couple of configuration files in the application's source code, committing them to the source control repository and typing rake remote:deploy!
Resilience
Each of the front-end components is effectively stateless. All of the user sessions are stored in MySQL (or memcached, depending upon the application) along with all the other persistent state. This means we don't need to implement expensive load balancers at the front end, in most cases. It also means that, if an application server fails (say there's a hardware issue with the server it's running on), then users will not be affected. Of course, this only works effectively once the application has scaled beyond a single server!