[asim]

As someone who scaled ruby on rails in the prime era 2007-2009 I'll tell you the problems have not changed. It's very straightforward horizontal scaling followed by load balancing across multiple nodes. Load relates having enough cores, fast enough disks and enough egress bandwidth throughput. Everything else is purely caching in front of a poorly performing ruby web server and minimising disk or database reads.

The write up is cool. Reminiscent of things we used to do back in that early rails 2-3 era. Just funny we're back where we started.

TLDR: if you want to run ruby on rails on bare metal be ready to run something with 8+ cores, 10k rpm disks minimum and more bandwidth than you can support out of your basement.

[pantulis]

Also, serving images from shared NFS mounts was not the best of ideas. I remember when S3 came out and the Rails attachment plugins ecosystem quickle added support; it was a godsend.

[ilyt]

even some hacked setup with 2 way sync is better. The dumbest (but still somehow the least problem in their architecture) I saw was running [1] syncthing on few servers and just syncing everything and hoping conflicts won't happen...

Like, I did it, but I wouldn't recommend it, restarting NFS server is gnarly, HA support on OSS side is... not really there last time I checked, and overall PITA.

* [1] https://syncthing.net/