El aprovisionamiento automático se ejecuta solo cuando
MULTI_TENANT_ENABLED=true. En despliegues single-tenant, los productos usan una única base de datos preconfigurada y omiten este ciclo de vida por completo.El ciclo de vida del aprovisionamiento
La incorporación de un tenant atraviesa cinco etapas. Cada etapa se construye sobre la anterior, finalizando con un tenant completamente aislado y listo para atender tráfico.
Creación del tenant
Se crea un tenant con su identidad y metadatos. En este punto el tenant existe solo como una identidad — el valor al que resolverá el claim
tenantId del JWT — pero todavía no tiene infraestructura asociada.Registro de servicio
Cada producto que el tenant usará se registra como un servicio bajo ese tenant — por ejemplo, Midaz Ledger o Tracer. El registro de servicio declara el modo de aislamiento (
DATABASE o SCHEMA) y la configuración que la plataforma necesita para aprovisionar y alcanzar los recursos del tenant.Aprovisionamiento automático de infraestructura
Registrar un servicio dispara el aprovisionamiento de la infraestructura aislada para ese tenant:
- PostgreSQL — una base de datos dedicada (en modo
DATABASE) o un esquema dedicado (en modoSCHEMA) para datos relacionales. - MongoDB — una base de datos aislada para datos documentales como metadatos.
- RabbitMQ — recursos de mensajería aislados (virtual host / colas) para los eventos asíncronos del tenant.
Migraciones
Una vez que la infraestructura existe, la plataforma ejecuta las migraciones de esquema del producto contra la nueva base de datos o esquema del tenant. Esto lleva el almacenamiento del tenant a la versión de esquema exacta que el producto espera, de modo que un tenant recién aprovisionado es estructuralmente idéntico a todos los demás tenants de ese producto.
Inicio de operación
Con la infraestructura aprovisionada, las credenciales resguardadas en el vault y las migraciones aplicadas, el servicio se marca como listo. El producto ya puede resolver el tenant desde su JWT, abrir una conexión aislada y comenzar a atender solicitudes. A partir de este punto el tenant opera exactamente como se describe en Multi-tenancy.
Qué se aprovisiona
| Recurso | Propósito | Aislamiento |
|---|---|---|
| PostgreSQL | Datos relacionales — organizaciones, ledgers, cuentas, transacciones, saldos, reglas, límites. | Base de datos dedicada (modo DATABASE) o esquema dedicado (modo SCHEMA). |
| MongoDB | Datos documentales como metadatos. | Base de datos dedicada por tenant. |
| RabbitMQ | Eventos asíncronos y mensajería entre servicios. | Virtual host / colas aisladas por tenant. |
| Credenciales | Acceso a los recursos anteriores. | Únicas por tenant, almacenadas en el vault de credenciales. |
Por qué el aprovisionamiento es centralizado
Anteriormente, la lógica de aprovisionamiento vivía solo dentro de los ámbitos de productos individuales (como el Matcher). Centralizarla a través de la capa de plataforma significa:
- Consistencia — cada producto aprovisiona un tenant de la misma manera, con las mismas garantías de aislamiento y la misma disciplina de migraciones.
- Una sola ruta de incorporación — agregar un tenant a un nuevo producto es un registro de servicio, no una configuración de base de datos a medida.
- Auditabilidad — el ciclo de vida del tenant y del servicio se rastrea en un solo lugar en vez de estar disperso entre productos.
Páginas relacionadas
Casos de uso
Las entidades de tenant y servicio que impulsan el aprovisionamiento.
Multi-tenancy
Cómo funcionan los modos de aislamiento y el escopado de tenants.
Seguridad
Resguardo de credenciales en vault, rotación y límites de recursos por tenant.