Pular para o conteúdo principal
Multi-tenancy permite que um único deployment atenda múltiplos clientes independentes — chamados tenants — com isolamento completo de dados entre eles. Cada tenant opera como se tivesse seu próprio ambiente dedicado, mesmo que a infraestrutura subjacente seja compartilhada. Na Lerian, o multi-tenancy está disponível em deployments SaaS (sempre ativo) e BYOC Multi-Tenant.

​
Como funciona

O isolamento de tenant é garantido na camada de aplicação por meio do seu token de autenticação.
  1. Você se autentica via Access Manager e recebe um JWT.
  2. Esse token inclui um claim tenantId que identifica o seu tenant.
  3. Em cada requisição à API, a plataforma resolve o seu tenant a partir do token automaticamente.
  4. Todas as operações — criar organizações, consultar ledgers, registrar transações — são escopadas ao seu tenant.
Você nunca precisa passar um identificador de tenant em headers ou no corpo das requisições. O token cuida disso.
O multi-tenancy é transparente no nível da API. Seu código de integração é o mesmo seja em single-tenant ou multi-tenant — a única diferença é que deployments multi-tenant exigem autenticação em toda requisição.

​
Relação entre tenant e organização

Um tenant não é a mesma coisa que uma organização. Um único tenant pode criar e gerenciar múltiplas organizações — por exemplo, para representar subsidiárias, filiais regionais ou diferentes unidades de negócio. 
Tenant (resolvido a partir do JWT)
├── Organização A
│   ├── Ledger 1
│   └── Ledger 2
├── Organização B
│   └── Ledger 3
Quando você lista organizações, só enxerga as que pertencem ao seu tenant. O mesmo se aplica a todos os recursos da plataforma — ledgers, contas, transações e saldos são todos escopados ao seu tenant automaticamente.

​
Isolamento de dados

Os dados de cada tenant são isolados no nível de banco de dados. Cada tenant opera em um banco de dados separado, o que significa:
  • Dados de diferentes tenants nunca são armazenados juntos.
  • Consultas de um tenant não conseguem alcançar os dados de outro tenant.
  • Mesmo que dois tenants criem estruturas organizacionais idênticas, seus dados permanecem completamente separados.
Esse isolamento é garantido por um middleware que roteia cada requisição para o banco de dados correto com base no claim tenantId do seu JWT. Não existe caminho na API para contornar isso.
Operadores BYOC podem escolher entre isolamento por banco de dados ou por schema, dependendo dos requisitos de infraestrutura.

​
O que isso significa para você

​
Se você é um cliente SaaS

Nada muda na forma como você usa a API. Autentique, obtenha seu token e faça requisições. A plataforma cuida do isolamento de forma transparente. Você não precisa gerenciar identificadores de tenant nem se preocupar com vazamento de dados entre clientes.

​
Se você é um operador BYOC rodando multi-tenant

Você configura quais tenants existem e como seus bancos de dados são provisionados. Seus clientes se autenticam pelo Access Manager e recebem tokens escopados. A plataforma roteia cada requisição para o banco de dados do tenant correto automaticamente.

​
Se você está rodando single-tenant (BYOC ou desenvolvimento local)

O multi-tenancy é desabilitado por padrão. Sua configuração existente continua funcionando sem alterações. Nenhum claim de tenant no JWT é necessário, e a autenticação pode ser opcional dependendo da sua configuração.

​
Páginas relacionadas

Modelos de deployment

Entenda as diferenças entre SaaS, BYOC Single-Tenant e BYOC Multi-Tenant.

Segurança

Saiba mais sobre as garantias de isolamento de tenant e o modelo de responsabilidade compartilhada.

Access Manager

Entenda como a autenticação e a resolução de tenant baseada em JWT funcionam.

Organizações

Saiba como as organizações são estruturadas dentro de um tenant.