Uma possibilidade seria criar uma tabela no banco de dados central que armazena informações da base de dados dos clientes. Com isso, você precisaria simplesmente fazer uma SELECT nessa tabela, recuperar as informações necessárias para montar a ConnectionString, conectar nas bases e fazer o que tem de ser feito.
Apesar deu nunca ter feito filas e nem cron jobs nesse cenário de multi tenancy, trabalhei em uma empresa que seguiu essa abordagem e seria assim que eu resolveria essa questão.
Como você abordaria esse cenário utilizando filas e cron jobs?
Então, depende muito do que se trata o procedimento em si. Alguns exemplos que consigo pensar:
1. Realizar o processamento de um pedido numa fila. Nesse caso, eu criaria uma tabela que representaria esse processamento em especifico na qual teria como uma de suas colunas o id dessa base de dados. Dai seria uma questão de recuperar esse registro, pegar o id da base e localizá-la na tabela do banco de dados central.
2. Criar um Cron Job que faz backup dos pedidos dos clientes 1x ao dia: quando ocorrer o trigger desse job, simplesmente faz um SELECT nessa tabela que contêm todas as bases de dados e faz o procedimento de backup na tabela de pedidos em cada base.
É lógico que dependendo dos requerimentos não vai ser tão simples assim. Mas eu acho que ter uma tabela que me diz quais são as bases dos meus clientes é essencial para que eu consiga fazer algo, a não ser que os colegas da plataforma possam sugerir outras abordagens, claro.
Eu fico arrepiado vom algumas ideias que vejo de vez em quando.
Como você resolveria essa questão?
A melhor forma para resolver essa questão (hoje) é a mesma dos grandes sistemas de mercado, um banco de dados armazena os dados de todos os clientes e trabalhamos o balanceamento conforme necessário, mais jamais separando banco por cliente. Como seria a manutenção disso depois? Para alterar um campo, uma procedure, uma function? Altera em todos os bancos, automatiza? Vai dar problema, com certeza.
Sim, concordo 100% que para realizar manutenção e escalar verticalmente o sistema centralizar tudo num DB é a melhor abordagem.
O ponto é que na pergunta do amigo ele diz que a empresa dele segue o caminho de dividir um banco para cada cliente. Nesse caso como eu imagino ser inviável mudar a arquitetura do sistema para seguir a abordagem que recomendados, a melhor forma de resolver o problema no contexto dele é centralizar as informações das bases num banco central. Não consigo enxergar outra forma de resolver esse caso.