I was really hoping for a bit more meat in this article. Perhaps some discussion on their caching strategy, or how they're building their JSON (i.e. traditional model-based #to_json approach, or something along the lines of Rabl).

Thanks for the RABL reference (https://github.com/nesquena/rabl), interesting stuff, perfect timing for one of my projects.

I'm using this on a project right now and am finding a lot of successes derived from its use. We tried to build our JSON in the model using the traditional #to_json/#as_json approach in Rails, but found this was falling on its face when our data model became more complex (which, itself, is probably a code smell, but that's another story).

Good luck! I hope it brings you success.

Agreed, not much to look at here. I would also be interested in hearing why they decided to roll their own platform instead of using a PaaS, given the small team size.

Because they are engineers working on their own things with no red-tape?

You could start with sharing how many instances you had at the peak, that would be useful.

Agreed. More details on if and how automatic scaling was implemented would be good too.

Thanks for the feedback, i'll try and cover all that in a future post.

Why would you actually go with Rails compared to a smaller framework? If all they are serving is JSON wouldn't something like Sinatra be better? Less fancy stuff they probably don't use anyway?

Linkbait; there's nothing here about either scaling or an iPhone app.

This article doesn't really bring anything new to the table - folks have been using this setup for a long time. They could at least talk about how they're managing deployment and scaling under high loads (manual? automated?), or how they're splitting the DB requests between the master and the slave under Rails.

According to the picture; does it mean that you have 4 instances (Rails) serving all traffic? I know that you can scale it horizontally. But, at the moment, is 4 the real number?

Agreed, really would like to see more technical information about this. A deeper dive is preferred...

This scales well for reads, but not for writes. The single MySQL instance is still handling all writes and (in it's current form) will have to be scaled vertically.

I see the EC2's are in different regions but not the RDS, can you choose which region your put your RDS in or is that not a factor?

To clarify they said "availability zones", not "regions", which is a huge difference in terms of latency. And yes, you can tell RDS which availability zone to use.

rl baoo