Diagrama de arquitetura SaaS multi-tenant: modelos silo, pool e ponte

Desenhe um produto SaaS multi-tenant do jeito que a maioria dos times desenha qualquer sistema, e ele fica idêntico a um sistema de locatário único: um gateway, alguns serviços, um banco de dados. A propriedade mais importante do sistema, quais dados de qual cliente podem ir parar onde, não aparece em lugar nenhum. Mas é justamente ela que orienta as decisões mais difíceis: como isolar os locatários (tenants), como atender os clientes grandes, como funciona o onboarding e o que um vizinho barulhento (noisy neighbor) pode quebrar.

Este guia mostra como tornar a multilocação visível em um diagrama de arquitetura: o vocabulário, o que mostrar, os modelos silo, pool e ponte (bridge) e um exemplo com recursos compartilhados e dedicados.

O vocabulário

Os termos abaixo são comuns em textos sobre arquitetura SaaS, incluindo as orientações de SaaS da AWS:

• Locatário (tenant). Uma organização cliente, com seus próprios usuários e dados.
• Plano de controle (control plane). Serviços que gerenciam locatários em vez de servir o produto: onboarding, registro de locatários (tenant registry), identidade, medição de uso e faturamento.
• Plano de aplicação (application plane). O produto em si: os serviços e armazenamentos de dados que os locatários usam no dia a dia.
• Contexto do locatário (tenant context). O ID do locatário que acompanha cada requisição, normalmente como um claim no token de acesso.
• Silo. Recursos dedicados a um único locatário, como um banco de dados separado ou uma stack completa.
• Pool. Recursos compartilhados por muitos locatários, separados por políticas e pelo ID do locatário.
• Ponte (bridge). Uma mistura dos dois: por exemplo, computação compartilhada com bancos de dados dedicados para alguns locatários.

O que o diagrama precisa mostrar

1. De onde vem o contexto do locatário. O provedor de identidade e o claim do token que carrega o ID do locatário.
2. Onde o isolamento é imposto. Não "no código", mas em um lugar específico: uma política de segurança em nível de linha (row-level security), um esquema por locatário, um banco de dados separado, uma política do IAM.
3. Quais recursos são compartilhados e quais são dedicados. Rotule cada armazenamento de dados e cada serviço como pool ou silo.
4. Como uma requisição encontra seus recursos. O roteamento ou a consulta (lookup) que envia um locatário para o banco de dados ou a stack certa.
5. Como os locatários são criados. O fluxo de onboarding que grava no registro e provisiona os recursos dedicados necessários.

Silo, pool e ponte

Modelo	O que é compartilhado	Pontos fortes	Custos
Silo	Nada no plano de aplicação	Isolamento forte, ajuste por locatário, respostas de compliance mais simples	Custo maior por locatário, mais implantações para operar
Pool	Computação e dados, separados pelo ID do locatário	Custo baixo por locatário, uma única implantação	O isolamento depende de cada consulta e de cada política; vizinhos barulhentos
Ponte	Algumas camadas compartilhadas, outras dedicadas	Investimento em isolamento onde ele importa	Dois caminhos para construir, testar e desenhar

Muitos produtos começam em pool e depois movem seus maiores clientes, ou os mais regulados, para silos, o que transforma o sistema em uma ponte. O diagrama deve deixar essa divisão evidente.

O exemplo: locatários em pool e um silo corporativo

Um produto de analytics B2B tem centenas de locatários padrão e um cliente corporativo, a Globex, que exige seu próprio banco de dados:

• Os usuários fazem login por um provedor de identidade que reconhece locatários. O token de acesso deles carrega tenant_id.
• O gateway de API valida o token e repassa o contexto do locatário para a API de analytics.
• A API de analytics consulta o nível (tier) e o banco de dados do locatário no registro de locatários.
• Os locatários padrão compartilham um banco PostgreSQL em pool, onde a segurança em nível de linha filtra cada consulta por tenant_id.
• A Globex recebe um banco de dados dedicado, provisionado pelo serviço de onboarding quando o locatário foi criado.

Duas molduras separam o plano de controle do plano de aplicação, e os rótulos nos armazenamentos de dados dizem qual modelo de isolamento se aplica. Agora um revisor pode fazer as perguntas certas: o que acontece se o registro cair, e quem pode mudar o nível de um locatário?

Regras para diagramas multi-tenant

Desenhe níveis, não locatários

Nunca desenhe uma caixa por cliente. Desenhe um caminho por nível ou modelo de implantação e dê nome a um locatário de exemplo se ajudar, como a Globex acima.

Rotule o contexto do locatário nas conexões

Escreva como o locatário é identificado em cada salto: JWT tenant_id, header X-Tenant-Id set by the gateway, tenant_id in the message. Jobs em segundo plano e consumidores de eventos também precisam do contexto do locatário, e é neles que ele mais se perde.

Mostre onde o isolamento é imposto

"Isolado por ID do locatário" é uma promessa; uma política de segurança em nível de linha, um esquema por locatário ou uma conta separada é um mecanismo. Rotule o mecanismo no armazenamento de dados ou adicione um nó Política ao lado.

Mostre os limites por locatário

Limites de taxa, cotas e limites de concorrência por locatário são a forma como um sistema em pool protege os locatários uns dos outros. Anote-os no gateway e nos serviços que os aplicam.

Mantenha medição e faturamento no plano de controle

Eventos de uso por locatário alimentam a medição e o faturamento. Desenhe-os no plano de controle, para que o plano de aplicação continue focado em atender requisições.

Erros comuns

• Sem plano de controle. Onboarding, registro de locatários e identidade são parte central da arquitetura, não ferramentas de administração.
• Isolamento por convenção. Uma nota dizendo "toda consulta filtra por locatário" não é um controle. Mostre a política que garante isso.
• Roteamento invisível. Se alguns locatários usam recursos diferentes, desenhe a consulta que decide isso.
• Caminhos assíncronos esquecidos. Filas, jobs agendados e exportações de analytics que perdem o ID do locatário são uma fonte clássica de vazamentos.
• Um diagrama gigante. Mantenha a residência de dados (regiões), a implantação e a visão lógica em diagramas separados.

Monte no Archboard

1. Entre com Google ou GitHub e crie um diagrama.
2. Adicione dois nós Moldura do pack Básico, Control plane e Application plane.
3. Adicione dois nós Caixa do pack Básico para os usuários padrão e os da Globex, um Provedor de identidade do pack Segurança, um Gateway de API do pack Nuvem e nós Contêiner do pack Modelo C4 para o serviço de onboarding e a API de analytics.
4. Adicione nós Postgres do pack Dados para o registro de locatários, o banco em pool e o dedicado, com o modelo de isolamento no rótulo.
5. Rotule as conexões com o contexto do locatário e deixe tracejada a conexão de provisionamento.

O exemplo usa 11 nós de diagrama, dentro do plano Free. Para a camada de nuvem e de rede por baixo, veja o diagrama de VPC da AWS e a página do caso de uso de nuvem.

Perguntas frequentes

Qual modelo de isolamento devo escolher? Parta dos requisitos dos seus clientes e do seu custo por locatário. O pool é o mais barato de operar, o silo é o mais fácil de explicar para um revisor de segurança e a ponte permite oferecer os dois. Escreva o motivo no diagrama.

Como mostro centenas de locatários? Você não mostra. Mostre cada nível ou modelo de implantação uma vez e mantenha a lista de locatários no registro, que é o lugar dela.

Cada locatário precisa do próprio diagrama? Não. Um diagrama por arquitetura, com os níveis nele. Um locatário corporativo em silo pode ganhar o próprio diagrama de implantação se rodar em uma conta ou região separada.

Como mostro a residência de dados? Com molduras de região em um diagrama de implantação separado, cada uma com as stacks ou os bancos de dados dos locatários que precisam ficar ali.

Onde ficam as chaves de criptografia por locatário? Ao lado dos armazenamentos de dados que elas protegem, como um nó do pack Segurança ou uma nota, junto com o serviço de gerenciamento de chaves que as guarda.

Comece grátis — um assento, sem cartão de crédito.