Multi-tenancy

Estratégia: Schema-per-Tenant

Cada empresa (tenant) possui um schema exclusivo no PostgreSQL. Isso garante isolamento total dos dados operacionais.

PostgreSQL
├── public              → Dados compartilhados
│   ├── tenants, users, process_roles
│   ├── form_definitions, robots, api_keys, webhooks
│   ├── notifications, attachments, dmn_templates
│   └── Flowable BPMN/CMMN Repository (ACT_RE_*, ACT_CMMN_RE_*)
│
├── tenant_acme         → Dados isolados da empresa "acme"
│   ├── Flowable BPMN Runtime/History (ACT_RU_*, ACT_HI_*)
│   ├── Flowable CMMN Runtime/History
│   ├── Flowable DMN Decision Tables (ACT_DMN_*)
│   └── Flowable Identity (ACT_ID_*)
│
└── tenant_globex       → Dados isolados da empresa "globex"
    └── ...

Componentes de roteamento

TenantFilter

Cada requisição HTTP deve incluir o header:

X-Tenant-ID: slug-do-tenant

O TenantFilter extrai esse header e armazena o tenant no TenantContext (ThreadLocal).

TenantAwareDataSource

AbstractRoutingDataSource que usa o valor do TenantContext para rotear cada conexão JDBC para o schema correto.

HikariCP por tenant

Cada tenant recebe um pool de conexões dedicado, criado no momento do provisionamento. O tamanho do pool é configurável por tenant.

Ciclo de vida do tenant

CREATING → ACTIVE ⇄ SUSPENDED → DEACTIVATED → DROPPED

Estado	Aceita requisições?	Dados preservados?
CREATING	Não	Sim
ACTIVE	Sim	Sim
SUSPENDED	Não	Sim
DEACTIVATED	Não	Sim
DROPPED	Não	Não — schema removido

Provisionamento assíncrono

Quando um tenant é criado via POST /api/admin/tenants, o provisionamento ocorre em background:

1. Tenant criado com status CREATING
2. @Async: CREATE SCHEMA tenant_<slug>
3. Flyway.migrate() com scripts de db/migration/tenant/
4. Flowable bootstrap (tabelas ACT_*)
5. HikariCP pool registrado
6. Status → ACTIVE

Em caso de falha, o status vai para FAILED com a mensagem de erro registrada.

Definições BPMN/CMMN — escopo global

Processos (BPMN) e Casos (CMMN) são publicados no schema public — são globais e compartilhados entre todos os tenants. Isso permite:

• Manutenção centralizada de processos
• Uma definição, múltiplos tenants executando

As instâncias são criadas em cada schema de tenant — o estado de execução é isolado.

DMN — escopo per-tenant

As tabelas de decisão (DMN) são armazenadas no schema de cada tenant. Isso permite que cada empresa customize suas regras de negócio sem afetar outras.

Migrações Flyway

Conjunto	Caminho	Executado quando
Shared	db/migration/	Startup do backend
Per-tenant	db/migration/tenant/	Provisionamento de cada tenant

Adicionando migrações de tenant

Ao criar um novo arquivo em db/migration/tenant/, ele será aplicado apenas a novos tenants criados após essa migração. Tenants existentes precisam ser migrados separadamente ou por uma migração shared que aplique o script em cada schema existente.