O provisionamento automático roda apenas quando
MULTI_TENANT_ENABLED=true. Em deployments single-tenant, os produtos usam um único banco de dados pré-configurado e pulam este ciclo de vida por completo.O ciclo de vida de provisionamento
O onboarding de um tenant percorre cinco estágios. Cada estágio se apoia no anterior, terminando com um tenant totalmente isolado e pronto para atender tráfego.
Criação do tenant
Um tenant é criado com sua identidade e metadados. Nesse ponto, o tenant existe apenas como uma identidade — o valor para o qual a claim
tenantId do JWT será resolvida — mas ainda não tem infraestrutura associada.Registro de serviço
Cada produto que o tenant vai usar é registrado como um serviço sob aquele tenant — por exemplo, Midaz Ledger ou Tracer. O registro de serviço declara o modo de isolamento (
DATABASE ou SCHEMA) e a configuração de que a plataforma precisa para provisionar e alcançar os recursos do tenant.Provisionamento automático da infraestrutura
Registrar um serviço dispara o provisionamento da infraestrutura isolada para aquele tenant:
- PostgreSQL — um banco de dados dedicado (no modo
DATABASE) ou um schema dedicado (no modoSCHEMA) para dados relacionais. - MongoDB — um banco de dados isolado para dados de documento, como metadados.
- RabbitMQ — recursos de mensageria isolados (virtual host / filas) para os eventos assíncronos do tenant.
Migrations
Uma vez que a infraestrutura existe, a plataforma executa as migrations de schema do produto contra o novo banco de dados ou schema do tenant. Isso leva o armazenamento do tenant à exata versão de schema que o produto espera, de modo que um tenant recém-provisionado seja estruturalmente idêntico a qualquer outro tenant naquele produto.
Início da operação
Com a infraestrutura provisionada, as credenciais no cofre e as migrations aplicadas, o serviço é marcado como pronto. O produto agora pode resolver o tenant a partir do seu JWT, abrir uma conexão isolada e começar a atender requisições. A partir desse ponto, o tenant opera exatamente como descrito em Multi-tenancy.
O que é provisionado
| Recurso | Finalidade | Isolamento |
|---|---|---|
| PostgreSQL | Dados relacionais — organizações, ledgers, contas, transações, saldos, regras, limites. | Banco de dados dedicado (modo DATABASE) ou schema dedicado (modo SCHEMA). |
| MongoDB | Dados de documento, como metadados. | Banco de dados dedicado por tenant. |
| RabbitMQ | Eventos assíncronos e mensageria entre serviços. | Virtual host / filas isolados por tenant. |
| Credenciais | Acesso aos recursos acima. | Únicas por tenant, armazenadas no cofre de credenciais. |
Por que o provisionamento é centralizado
Anteriormente, a lógica de provisionamento vivia apenas dentro dos escopos de produtos individuais (como o Matcher). Centralizá-la na camada de plataforma significa:
- Consistência — todo produto provisiona um tenant da mesma forma, com as mesmas garantias de isolamento e a mesma disciplina de migrations.
- Um único caminho de onboarding — adicionar um tenant a um novo produto é um registro de serviço, não uma configuração de banco de dados sob medida.
- Auditabilidade — o ciclo de vida de tenants e serviços é rastreado em um único lugar, em vez de espalhado pelos produtos.
Páginas relacionadas
Casos de uso
As entidades de tenant e serviço que conduzem o provisionamento.
Multi-tenancy
Como os modos de isolamento e o escopo de tenant funcionam.
Segurança
Cofre de credenciais, rotação e limites de recursos por tenant.