It goes without saying that there are a lot of things one would do prior to some of these steps. Because of the complexity these sort of configuration bring int

It goes without saying that there are a lot of things one would do prior to some of these steps. Because of the complexity these sort of configuration bring into your app one should weigh carefully whether they need these approaches. Database tuning and caching are preferable first steps in an app faced with performance challenges before fancy database routing. As with caching the app awareness of these approaches leaks into your code and can introduce testing challenges and misses in your process. Maybe I missed it but I’m surprised they didn’t mention Multi-Tenancy with Multi-Database since they have otherwise written about it*. For many apps this is not only a way to keep data isolated but is also a way to mitigate performance challenges that might come with a single large DB. https://blog.appsignal.com/2020/12/02/building-a-multi-tenant-ruby-on-rails-app-with-subdomains.html https://blog.appsignal.com/2020/12/02/building-a-multi-tenan...