Rails is great if what you’ve got is read-mostly cachable content being served up. In an environment with high rates of incoming data, most of which can’t be reliably cached, things get more interesting and you start needing to scale horizontally a lot more and leaning on the database.

Scaling horizontally is not cheap. A faster language needs fewer replicas.

Rails handled Black Friday and Cyber Monday traffic for an ecommerce company I used to work for just fine. If you are making money, it's worth the cost of 50 lowend VPSes autoscaled (we could have done with a lot less, too).

If we were using Java it would have taken us three times the people and four times as long to build the site, and we all would have been laid off.

For rare events this concept works fine. For large sustained loads using more language/runtime could save a fortune.

Do you have a real world example? For example, what are you spending on a single app server? And how many RPS should it handle?

Not if you hired better people.

> Rails handled Black Friday and Cyber Monday traffic for an ecommerce company I used to work for just fine.

That says nothing about the added cost of running inefficient services, which require additional nodes to serve the same requests and thus increase operational cost and also risk to perform the same service.

Really? Our frontend servers handle 50 rps and cost $20 each and are nowhere near peak utilization. If anything ever needs scaling its the database. What level of traffic are you talking about?

For example a newspaper with customizable content, 1 petabyte (70% video) per month and avg. 2k request per second.

I don’t want to second guess technical decisions I know nothing about but: no, Rails shouldn’t be streaming video. But 2k requests per second with mostly text content being shuffled around sounds absolutely doable with Rails. The cost benefit of easier development should definitely not be understated as well.

But that being said, the primary driver for tools should be what the developers know and ease of access finding developers who know this technology. If the city you work in mostly has PHP developers, PHP is a great choice. Similar for Java, Haskell, Lisp, etc. My point is that the tool ”Rails” definitely is adequate for this problem (minus streaming video...). Look at Shopify, Github or any other massive Rails app

> I don’t want to second guess technical decisions I know nothing about but: no, Rails shouldn’t be streaming video.

Yeah, if you are serving video at that rate, there are plenty of CDNs to work with, why would you submit your app engine to that.

If a Rails back-end streamed video, there wouldn't literally be a loop written in Ruby shoving bytes back and forth stored in Ruby arrays or buffers. It would be farmed off to something appropriate. You wouldn't necessarily want that machine to be doing it, using any middleware.

Which newspaper is hitting 2k req/s ?

For example:

https://stackoverflow.com/a/373188

> Wikipedia seems to be 30000 to 70000 [requests] per second spread over 300 servers

So 2k is not unusual for bigger news sites, that may or may not employ a (few) rails team(s).

That’s only 100-250rps per server, that’s really not very hard in any framework.

Financial exchanges are doing 100,000rps of transactions per sever. That’s hard.

Compared with developer time servers are cheap. Even for a single developer being 10% quicker at development equates to dozens to a hundred servers.

Yet somehow the popular industry pattern adopted by the industry is to waste ad much developer time as possible.

I never understood this until I was self-employed. I now feel this in my soul.