That question is far to generic to have a useful answer. If you want to know how to design for scalability, you need to be more specific about what needs to scale and how than just "a Ruby on Rails web app".
There are a number of different things that can scale in an application, and what you need to make one of them scale well may be counterproductive to scaling another one.
OTOH, you are probably worrying about scalability at exactly the wrong time. You either should have a clear problem to address (which you haven't yet reached), or if you know what your scalability concern is before you've started writing your app (much less encountered an actual pragmatic problem), you should be asking that question before you choose the implementation language and framework (since particular choices there may be part of the solution.)
https://www.hnsearch.com/search#request/all&q=web+framework+...
Performance really is relative. As they say: "If you always optimize for the future, you will never get there"
Many high end sites are run on rails. Load balancing/clustering will handle most traffic problems you might run in to.
A common problem I've observed several times with low-performance frameworks is that you can run into performance pain before you've adequately vetted your project's ability to convert customers. By comparison, a high-performance framework allows you to be experimental and relatively reckless with your application logic. Your application code can be closer to brute-force with a high-performance platform, meaning you can optimize the application code later when the time comes, rather than bringing out the big guns of scalability.
Rails isn't the answer to every programming problem, but I don't think that Rails has any more of a scalability issue than any other framework.
If you avoid doing things that absolutely won't scale you will be fine. Rails has no issues scaling, for 99.9% of the use cases. Regardless of the framework you use you will still have plenty of scaling issues if you have Twitter/Facebook level of success. But again that is a great problem to have.
- avoid n + 1 queries - shorten response time as much as possible without caching (focus on good code, avoid logic etc..., least db queries as possible)
- anything that takes longer than 100ms to process I use async processing to handle it.
(in Spanish, "excelente" means "admirable")
If you're bringing in enough customers to cause you scaling problems, then that's a good position to be in.