The irony is that in a normal Rails app workloads are already split by default (requests and background jobs are handled by different processes that share the same codebase).
Yep, it's a very normal thing in the Rails world to separate things like this. For Django too.
I'd encourage people to look a past just the splitting of workloads though. The other point about resource limits for shared resources across workload tiers is really key, such as having very granular database connection pools even inside of a single workload deployment.
That's less common – though not unheard of – in Rails-land.
