Separation of services is orthogonal to separation of concerns. There's nothing stopping you from having multiple entry points into the same monolith. I.e. web servers run `puma` and workers run `sidekiq` but both are running the same codebase. This is, in fact, the way that every production Rails app that I've worked with is structured in terms of services.

Concerns (in the broad sense, not ActiveSupport::Concern) can be separated any number of ways. The important part is delineating and formalizing the boundaries between them. For example, a worker running in Puma might instantiate and call three or four or a dozen different service objects all within different engines to accomplish what it needs, but all of that runs in the same Sidekiq thread.

Inserting HTTP or gRPC requests between layers might enforce clean logical boundaries but often what you end up with is a distributed ball of mud that is harder to reason about than a single codebase.

For your example, rails apps handle this case by default with job queues that are managed by the deployment separately. There is a way to force the job queue to process in the same process as your web server, but that's not the way most should be running prod rails apps. There usually isn't anxiety associated with rails app deploys, in my experience.

What can you not do in a monolith? You can still have async queues and different event processors that stop and start independently within a monolithic deployment.