Ehrm, Scales?

Yes, Scales is the product of a master thesis called Super Scale Systems by Thomas Fankhauser (2012).

It is a ruby gem that follows the design goal to scale by design. One of the major design goals is to keep 100% of all resources in the cache at all times. The application that uses Scales needs to make sure that all data is permanently up-to-date. To allow a perfect hardware scaling, Scales divides the responsibilities in the following modules:

Cache
Stores 100% of the resources of the system and uses a Redis for key/value and PubSub
Servers
Lookup resources or delegate them to workers and use Ruby's EventMachine at their core
Workers
Process requests and update the cache and use Ruby on Rails as their application

Because of this clear division where the components talk over an asynchronous job queue, the language and framework that is used to process the requests doesn't matter. Currently all of the modules are implemented in Ruby. It would be very interesting to see the combination of NodeJS servers and Ruby on Rails workers to benefit from the best of both worlds.

To stay updated you can follow me on twitter

Request Flow

When a request hits the server the server extracts the request URL and the HTTP verb. If the request is a GET request it assumes that there is an entry with that URL in the cache. It tries to look it up, and serves it or returns a 404. There is no fallback, so the worker has to make sure that all resources are pushed to the cache.

When a request other than GET is received, the server puts the request in a job queue and waits for a worker to process it.

The worker takes the job from the queue and requests the application for the URL. The application then does the usual processing, like deleting a resource or creating one. It additionally writes or deletes the newly created or deleted resource to and from the cache. After it is done with it, the worker publishes the response to the server who returns it to the client. Summarized this looks like this:


Load Driven Hosting

The benefit from this setup now is that every module can be scaled if it's needed. If the server is to slow handling all the incoming requests you can simply add, another server and double the amount of requests per second.

If the processing takes to long you can simply add more worker machines that will execute each process truly parallel.

If the cache is to slow, you can simply add a slave using redis slaveof ip command. Often the design might look like this:

Fork me on GitHub
 
Scales is made by Thomas Fankhauser for southdesign.de