This is standard practice on monolithic apps. It is effectively an N-tier architecture. On Rails it is very expected that you would deploy the same codebase to two tiers (web and worker) and simply run rails s in one and sidekiq in the other.
But outside of these frameworks, you won’t often see it. And especially in languages like Go which tend to avoid opinionated frameworks it’s common not to see a split like this, even when it might be really beneficial.
As with most programming concepts, standard practice varies a lot depending on the tools you use. It’s why I thought this post was worth writing, in that there are many people who haven’t run Rails/etc frameworks before and may not have considered this approach!
[0] https://python-rq.org/ [1] https://github.com/rq/django-rq [2] https://github.com/rq/rq-scheduler
django-postgres-queue: https://github.com/gavinwahl/django-postgres-queue
procrastinate: https://github.com/procrastinate-org/procrastinate/