Isolamento de tenentes e limites

O isolamento dos tenentes e os limites são as fundações da arquitetura multi-tenente. O objetivo é garantir que as ações de um inquilino nunca afetem os dados, a segurança e o SLO do outro, e que os recursos sejam distribuídos de forma justa e previsível. Abaixo, um mapa prático de soluções que vão do nível de dados ao planejamento computacional e gerenciamento de incidentes.

1) Modelo de ameaças e metas

Ameaças

Vazamento de dados entre locatários (lógico/por cachê/logs).
Noisy neighbor: Piora de desempenho devido aos destaques de um único cliente.
Escalar privilégios (erro na política de acesso).
Billing drift (inadequação entre uso e pagamento).
Cenários em cascata resistentes a falhas (um incidente de um leva ao downthame de muitos).

Alvos

Isolamento rigoroso de dados e segredos.
Limites/quotas para tenante e planejamento justo.
Auditoria transparente, observabilidade e billing.
Localização de incidentes e recuperação rápida per tenant.

2) Níveis de isolamento (modelo de transição)

1. Dados

'tenant _ id' em chaves e índices, Row-Level Security (RLS).
Criptografia: hierarquia KMS → chave de locação (KEK) → chaves de dados (DEK).
Esquemas separados/BB de alta exigência (Silo), cluster com RLS compartilhado para eficiência (Pool).
Políticos retensia e «direito de esquecimento» per tenant, crypto-shredding chaves.

2. Cálculos

Quotas de CPU/RAM/IO, pool de workers por tenente, filas «ponderadas».
Isolamento GC/heap (contêineres/configurações JVM/Runtime), limites de paralelismo.
Para-tenente autoscaling + backpressure.

3. Rede

Segmentação: private endpoants/VPC, LCA por 'tenant _ id'.
Rate limiting e per-football connation caps no limite.
Proteção contra DDoS/bots com base no plano/prioridade.

4. Operações e processos

Migrações de pouso, bacapes, DR., função-flags.
Os incidentes são «micro-blast-raio», foguete por «tenant _ id».

3) Controle de acesso e contexto do locador

AuthN: OIDC/SAML; os tokens carregam 'tenant _ id', 'org _ id', 'place', 'scopes'.
AuthZ: RBAC/ABAC (papéis + atributos do projeto, departamento, região).
Contexto de limite: A entrada API extrai e valida o contexto do tenente, complementa os limites/quotas, escrevendo para os trailers.
O princípio do «duplo castelo» é verificar o serviço + RLS/política de base de dados.

4) Dados: circuitos, dinheiro, logs

• Shared-schema (row-level): máxima eficiência, RLS rigoroso é obrigatório.
• Per-schema: comprometimento de isolamento/operabilidade.
• Per-DB/cluster (Silo): para VIP/regulados.

Cash: prefixes de chaves 'tenant: Se você não quiser saber, o TTL de planos, a protecção contra cachê-stampede (lock/early refresh).

Logi/metadados: pseudônimo completo PII, filtros por 'tenant _ id', proibição de 'pente' de logs de aluguéis diferentes.

5) Limitação de tráfego e operações

Mecânicos básicos

Token Bucket: picos suaves, configuração 'rate '/' burst'.
Leaky Bucket: estabilização throughput.
Fixed Window/Sliding Window: quotas simples/precisas na janela de tempo.
Concurrency limits: caps para consultas simultâneas/jobs.

Onde aplicar

A porta de entrada L7/API é a principal proteção e «falha rápida».
No centro (serviços/filas), para o segundo circuito e para o «fair share».

Políticas

Por tenante/plano/endpoint/tipo de operação (API pública, exposição pesada, ação admin).
Priority-aware: VIP ganha mais 'burst' e peso na arbitragem.
Idempotency-keys para retrações seguras.

Exemplo de perfis (noções)

Starter: 50 req/s, burst 100, 2 exportações paralelas.
Business: 200 req/s, burst 400, 5 exportações.
Enterprise/VIP: 1000 req/s, burst 2000 s, workers dedicados.

6) Quotas e planejamento justo (fairness)

Quotas de recursos: armazenamento, objetos, mensagens/min, tarefas/hora, tamanho das filas.
Weighted Fair Queuing/Deficit Round Robin: acesso «ponderado» a workers compartilhados.
Per-tenant worker pools: isolamento rígido para clientes ruidosos/críticos.
Controle de admissão: falha/degradação antes que as quotas sejam esgotadas.
Backoff + jitter: atrasos exponenciais para não sincronizar os destaques.

7) Observabilidade e billing per tenant

As marcas obrigatórias são «tenant _ id», «place», «region», «endpoint», «status».
SLI/SLO per tenant: p95/p99 latency, error rate, availability, utilization, saturation.
Métricas Usage: Contadores de operações/bytes/segundos CPU → agregador → faturas.
Idempotidade billing: snapshots na fronteira, proteção contra duplo cancelamento/perda de eventos.
Os segmentos de dashboards são VIP/regulados/novos inquilinos.

8) Incidentes, degradação e DR. «por locadores»

Fusing por 'tenant _ id': desligamento de emergência/trottling de um locador específico sem impacto sobre os outros.
Graceful Descradation: modo read-only, filas no banco de areia, tarefas adiadas.
RTO/RPO per tenant: metas de recuperação e perdas para cada plano.
Exercícios: «game days» regulares, desligando o locador barulhento e verificando o DR..

9) Conformidade (residency, privacidade)

Cinning tenante para a região; regras claras para os fluxos cruzados-regionais.
Auditoria de acesso a chaves/dados, registro de operações de admin.
Gerenciamento de retino e exportação de dados per tenant.

10) Mini-árbitro: como juntar

Fluxo de consulta

1. Edge (API): O TLS → extrair 'tenant _ id' → validar o token → aplicar rate/cotas → fazer trailers.
2. Pólio-motor: contexto 'tenant _ id/place/featuras' → uma solução de rota e limites.
3. Serviço: Verificação de permissões + RLS 'tenant _ id' Operação com banco de dados sob RLS em dinheiro prefixado.
4. Coleta Usage: Contadores de transações/bytes → agregador → billing.

Dados

Esquema/BD de estratégia (row-level/per-schema/per-DB).
KMS: chaves por locador, rotação, crypto-shredding quando removido.

Cálculos

Filas com balanças, poulas de worker per tenant, caps por concurrency.
Autoscaling por métricas para-tenantes.

11) Políticas pseudo-políticas (para orientação)

yaml limits:
starter:
req_per_sec: 50 burst: 100 concurrency: 20 exports_parallel: 2 business:
req_per_sec: 200 burst: 400 concurrency: 100 exports_parallel: 5 enterprise:
req_per_sec: 1000 burst: 2000 concurrency: 500 exports_parallel: 20

quotas:
objects_max: { starter: 1_000_000, business: 20_000_000, enterprise: 100_000_000 }
storage_gb: { starter: 100,   business: 1000,    enterprise: 10000 }

12) Folha de cheque antes de vender

• Uma única fonte de verdade 'tenant _ id'; Por todo o lado, passa-se e loga-se.
• RLS/LCA ativado no nível BD + verificação de serviço (fechadura dupla).
• Chaves de criptografia per tenant, documentada rotação/remoção (crypto-shredding).
• Limites/quotas na fronteira e no interior; picos testados e «burst».
• Fair-queuing e/ou workers dedicados para VIP; caps на concurrency.
• Para-tenentes SLO e alertas; dashboards em segmentos.
• A coleta usage é idimpotente; O acordo com o Billing foi verificado.
• Dr./incidentes são localizados até o locador; A fusing por 'tenant _ id' funciona.
• Cases/logs divididos por locadores; O PII está mascarado.
• Os procedimentos de migração/bacaps/exportação são paramentais.

13) Erros típicos

O RLS foi desativado/não por um usuário «de serviço» - risco de fuga.
Um único limite global → «noisy neighbor» e violação do SLO.
Cachês compartilhados/filas sem prefixo → cruzamento de dados.
O Billing conta pelos logs que se perdem nos picos.
A falta de fusing de porão é uma queda em cascata.
Migração «com apenas um passo» sem a opção de «tenant _ id» problemático.

14) Escolha rápida de estratégia

Dados regulados/VIP: Silo (per-DB), brokers dedicados, quotas rigorosas e residency.
SaaS em massa: Shared-schema + RLS, limites fortes na fronteira, fair-queuing dentro.
Carga de barulho/pulso: grandes 'burst' + duros concerrency-caps, backpressure e prioridades de planos.

Conclusão

O isolamento dos tenentes e os limites são sobre fronteiras e justiça. Claro 'tenant _ id' através da pilha, RLS e criptografia de dados, limitação e quotas na fronteira e no coração, planeador justo, observabilidade e localização de incidentes - tudo isso, juntamente, oferece segurança, qualidade previsível e bilhetagem transparente para cada locatário, mesmo com o crescimento agressivo da plataforma.