The Minimum Viable Rails Stack, Now Reddit Frontpage Approved

This is almost exactly how I deployed NameTerrific (<a href="https://www.nameterrific.com" rel="nofollow">https://www.nameterrific.com</a>). It automatically gets ready for any horizontal scaling in the future.<p>In addition, I allocate the workers to their own instances so that they can grow independently. Also I use Capistrano to automate deployment. Whenever additional resources are needed, simply clone the instance and add it to the load balancer.<p>I use 2 Nginx workers and 8 Unicorn workers in a single app instance, and they serve in HTTP at 80 and 443 (yes they respond in HTTP via port 443 and the app should assume it's HTTPS). The app instances are firewalled in a private network and they use private IP addresses.<p>The load balancer has two networking interfaces, one public-facing and one private-facing. It's basically a reverse proxy serving traffic in both HTTP and HTTPS (which will be forwarded to HTTP:443). So the load balancer handles the encryption entirely.<p>The assets get compiled during deployment, and everything gets cached. I bundle all the CSS and JS into a single package, so that there's nothing to load other than the HTML and images (natively async) in subsequent visits. The website is simply way more responsive when deployed this way. I also use CloudFront to host the assets by simply pointing the cloud distribution to the website itself as the origin. Rails will handle the assets host automatically as well.<p>Whenever I need to deploy or manage the database directly for any reason, I will need to connect to the private network via VPN. It's secure and just neat.<p>If I need to build a local mirror, I'll install another nginx box, connect to the VPN, and reverse proxy HTTPS requests to the HTTP:443 directly. This reduces the HTTPS handshaking latency while still maintaining the security. And it just works.<p>EDIT: Added a link to make it easier for the curious people.

"We didn’t have any page caching in place at all."<p>Cache me if you can! If you're a high-traffic site and you are not caching static content (I recommend Varnish highly), then your are throwing money or good user experience out the window.

Great post, it is great to see startups being open about how they architect their systems and overcome issues with scaling.<p>This sort of information helps people building the next group of startups save both time and money.<p>Keep up the great work!

Well done guys, keep scaling and keep representing the Melbourne tech scene!

We used New Relic for a while with Heroku but turned it off because of a number of performance and stability issues we seemed to be seeing with it. In particular application boot times (for the first requests anyways) seemed to be negatively affected.

While the "webscale" method with nginx you detailed is nice [1], why not use Varnish or nginx's built in proxy_cache features [2]?<p>[1] <a href="https://gist.github.com/3711251" rel="nofollow">https://gist.github.com/3711251</a><p>[2] <a href="http://wiki.nginx.org/HttpProxyModule#proxy_cache" rel="nofollow">http://wiki.nginx.org/HttpProxyModule#proxy_cache</a>

Nice post, but:<p>Don't self-back-pat.<p>It read more like marketing for the company than anything of much worth.<p>Don't use the words "web scale".<p>It is a meaningless term. How many requests per second and how many guest and user sessions for how long of a time is "web scale"? Does "web scale" just mean Christmas shopping traffic on your crappy e-commerce site that no one visits, does it mean you can survive being top link on HN on a Friday morning, or slashdotted, or DoS attacked by anonymous, or survive a fucking flood and the data center lifts off the ground and enough flexibility and strength in the trunk lines to handle a tsunami?<p>Don't just throw users at it.<p>Unless testing is very costly and you need every user's eyes on your untested code as possible, that is just stupid. Look at Tsung, Grinder or JMeter, or the many other ways you could generate load as a first step before you do that.<p>Don't gloss over the details.<p>Sure you said you were using Rails 3.2 and postgres and a tad bit about the architecture, but who in the hell <i>doesn't</i> know that you need to load balance, need to put the DB servers on different VMs/servers than the apps. Although- having everything on both and some stuff just not turned on and live is not a bad idea for emergency fault tolerance, and you didn't mention that.

A few questions:<p>1. Is it possible to spin up two apps on Heroku? 2. What load balancers are available with the above? 3. Anyone have a link to a run down of how to back up your Postgres DB periodically?<p>Thanks

Great job! Can you do such page for EC2 too?

we have pretty much used a similar stack in websketch.com