Níveis de maturidade de Tenant em TI (SaaS) | Arquitetura
- Níveis de maturidade de Tenant em TI (SaaS) | Arquitetura
Níveis de maturidade de Tenant em TI (SaaS) aplicado a Gateway de Pagamentos
Este documento descreve os principais níveis de maturidade no uso de tenant em sistemas SaaS multi-cliente, com foco em gateway de pagamentos, seguindo o modelo de evolução de arquitetura: de ambientes dedicados até multi-tenant escalável.
Conceito de Tenant no contexto de Gateway de Pagamentos
Em um gateway de pagamentos, um tenant representa uma empresa/merchant/cliente dentro da plataforma.
Um tenant normalmente possui:
- credenciais próprias (API Key, tokens)
- configurações próprias (split, antifraude, limites, webhooks)
- dados isolados (pagamentos, estornos, chargebacks, relatórios)
- regras de permissão e acesso (usuários, perfis, RBAC)
SaaS Maturity Levels aplicados a Tenant
Level 1: Custom Tenant
Neste nível, cada tenant tem uma instância própria e geralmente com alto grau de customização.
Características:
- um ambiente para cada cliente
- infraestrutura dedicada por cliente
- pode ter variações de código e configuração por tenant
Exemplo em gateway de pagamentos:
- Cliente A possui um deployment exclusivo do gateway
- Cliente B possui outro deployment exclusivo
- cada cliente tem seu próprio banco, filas e rotas de integração
Vantagens:
- isolamento máximo de dados e performance
- customizações específicas por cliente mais fáceis
Desvantagens:
- alto custo operacional
- difícil escalar para muitos tenants
- manutenção e deploy complexos (um por cliente)
Level 2: Single Tenant
Cada tenant ainda tem uma instância própria, porém mais padronizada e menos personalizada.
Características:
- um ambiente por cliente
- padrão técnico único (mesma aplicação, mesma estrutura)
- separação forte (infra e dados dedicados)
Exemplo em gateway de pagamentos:
- cada merchant enterprise recebe um ambiente exclusivo
- cada ambiente tem seu banco, seus serviços e seus logs
- integrações, antifraude e webhooks são isolados por instância
Vantagens:
- isolamento forte
- previsibilidade de performance
- segurança e compliance mais simples de auditar
Desvantagens:
- custo de infraestrutura por cliente ainda alto
- dificuldade para atender muitos clientes pequenos
- upgrades precisam ser aplicados em várias instâncias
Level 3: Multi Tenant
Uma única instância da aplicação atende vários tenants ao mesmo tempo, com isolamento lógico.
Características:
- uma aplicação compartilhada para múltiplos tenants
- separação via tenant_id / merchant_id
- configuração e controle centralizado
Exemplo em gateway de pagamentos:
- o mesmo endpoint
/paymentsserve todos os clientes - a API Key determina o tenant de cada requisição
- os dados são armazenados com uma chave de isolamento (ex:
tenant_id)
Pontos comuns de implementação:
- tabelas com coluna
tenant_id - autorização aplicada em todas as queries
- regras e preferências por tenant armazenadas em configurações
Vantagens:
- custo menor por cliente
- escala melhor para grande quantidade de merchants
- manutenção simplificada (um deploy atende todos)
Desvantagens:
- falhas de autorização podem causar vazamento entre tenants
- risco de “noisy neighbor” (um tenant impactar outros)
- observabilidade e troubleshooting exigem mais maturidade
Level 4: Scalable Multi Tenant
Evolução do multi-tenant tradicional com foco em escalabilidade, resiliência e governança.
Características:
- multi-tenant com capacidade de escalar automaticamente
- proteção contra picos e abuso por tenant
- arquitetura preparada para alto volume
Exemplo em gateway de pagamentos:
- autoscaling automático para processar picos de pagamentos
- filas de eventos para desacoplar processamento (ex: confirmação, webhook, conciliação)
- rate limit por tenant (por API Key ou merchant_id)
- isolamento de performance com balanceamento e particionamento
Mecanismos comuns:
- particionamento por tenant (ex: shard por merchant_id)
- circuit breaker e retries para integrações externas
- métricas, logs e alertas segmentados por tenant
- filas e consumidores escaláveis (ex: workers por tipo de evento)
Vantagens:
- suporta milhares/milhões de transações com estabilidade
- reduz impacto de picos (Black Friday, campanhas, viradas)
- operação sustentável com crescimento do número de tenants
Desvantagens:
- arquitetura e operação mais complexas
- exige maturidade em observabilidade, SRE e governança
Comparativo rápido dos níveis
| Nível | Arquitetura | Isolamento | Escala | Custo por tenant | Operação |
|---|---|---|---|---|---|
| Level 1 | instância + custom por tenant | muito alto | baixa | alto | difícil |
| Level 2 | instância dedicada por tenant | alto | média | alto/médio | média |
| Level 3 | instância compartilhada | lógico | alta | baixo | média |
| Level 4 | instância compartilhada escalável | lógico + controle avançado | muito alta | baixo | complexa |
Como identificar o nível atual em um Gateway
Perguntas práticas:
- existe um ambiente separado por cliente?
- a base de dados é compartilhada entre clientes?
- existe tenant_id em todas as entidades críticas (payments, refunds, chargebacks)?
- rate limit e quotas são aplicadas por tenant?
- existe visibilidade de métricas e falhas por tenant?
- é possível escalar processamento automaticamente sem intervenção manual?
Interpretação:
- instância por cliente → Level 1 ou Level 2
- instância compartilhada com tenant_id → Level 3
- multi-tenant com autoscaling, isolamento de carga e governança → Level 4