Desenvolvimento Web e de Software

Criar uma arquitetura multitenant para um produto SaaS

Uma arquitetura multitenant serve várias organizações na mesma aplicação SaaS, isolando dados e permissões de cada uma.

O que contém este artigo?

Uma arquitetura multitenant serve várias organizações na mesma aplicação SaaS, isolando dados e permissões de cada uma.

Má conceção de tenants pode causar fugas e problemas de desempenho. A identidade do tenant deve ser central na arquitetura.

O que é um tenant?

Um tenant é um espaço separado de cliente ou organização. Conforme o sistema, um utilizador pode pertencer a um ou vários.

Modelos de isolamento de dados

  • Base de dados comum e esquema comum
  • Base partilhada, esquemas separados
  • Base separada por tenant

Abordagem da Base de Dados Compartilhada

tenant_id em cada registo facilita a operação, mas todas as consultas devem aplicar o âmbito do tenant.

A abordagem de base de dados separada

Pode proporcionar um isolamento físico mais forte, mas aumenta a migração, gestão de conexão, monitorização e complexidade de custos.

Autorização

Aplique centralmente acesso apenas aos dados do tenant do utilizador através de middleware, políticas ou repositórios.

Contexto do tenant

Identifique o tenant numa fonte fiável e mantenha o contexto imutável na aplicação.

O problema do vizinho ruído

Um tenant com consumo excessivo pode afetar outros. Podem ser necessários limites de pedidos, filas separadas ou quotas.

Faturamento e gestão de planos

Modele funções, limites de utilizadores, armazenamento e faturação por uso por tenant.

Auditoria e segurança

  • Registar o ID do tenant
  • Testes de acesso entre tenants
  • Validação do papel
  • Âmbito de tenant dos tokens API
  • Estratégia de cópias de segurança e restauro

Colocar decisões de projeto em prática

Relacione as decisões sobre tenants, modelos de isolamento e bases partilhadas. Defina funções, fontes de dados, papéis, limites de segurança, dependências e métricas de sucesso. Converta-os em backlog, critérios de aceitação e lista de riscos para acompanhar resultados mensuráveis em vez de interpretações pessoais.

Uma solução empresarial que funciona hoje não é necessariamente sustentável a longo prazo. Inclua código testável, implementação, registos, monitorização, migração e rollback na arquitetura inicial. Isto controla o retrabalho e os custos operacionais das versões seguintes, em vez de apenas atrasar o desenvolvimento.

Lista de implementação e riscos técnicos

Uma lista de funções não basta. Registe desde o desenho técnico as decisões sobre tenants, modelos de isolamento e bases partilhadas. Defina equipa, fonte, comportamento esperado, falha e critério de aceitação por requisito crítico. Isto reduz discussões de âmbito posteriores e cria uma referência comum para produto, desenvolvimento, operações e negócio.

Avalie separadamente dependências, permissões, integridade dos dados, falhas externas e escala prevista. Nas API, preveja tempos limite, limites de frequência, pedidos duplicados, divergências e falhas temporárias, não apenas respostas bem-sucedidas. Auditoria, rollback ou novas tentativas facilitam a recuperação segura após erros.

Antes da entrada em produção, defina metas mensuráveis: duração das operações, acesso por função, retenção de registos e acompanhamento de erros. Depois, monitorize registos, erros, desempenho da base, filas e latências externas críticas. Isto ajuda a detetar problemas sem depender apenas de queixas e a gerir um produto sustentável em vez de um projeto pontual.

  • Relacionar funções com critérios de aceitação
  • Controlos de autorização e acesso aos dados
  • Cenários de falha API e integração
  • Abordagem de backup e rollback
  • Monitorização e acompanhamento de erros
  • Metas de desempenho e capacidade

A abordagem de software da B10 Digital Agency

A B10 Digital Agency trata software à medida como desenvolvimento de produto digital, não apenas ecrãs: processos, UX/UI, arquitetura, API, segurança, DevOps e medição são concebidos em conjunto.

Perguntas frequentes

É necessária uma base de dados separada para cada cliente?

Não. O modelo depende de segurança, escala e operação.

tenant_id basta para a segurança?

Não. O campo não basta; todas as camadas de acesso devem aplicar o âmbito do tenant.

Um utilizador pode pertencer a vários tenants?

Sim, conforme o modelo de negócio; conceba a pertença separadamente.

Pode acrescentar-se multitenancy depois?

Sim, mas migrar pode ser complexo se o modelo não considerar tenants desde o início.

Artigos relacionados

Planeje seu projeto de software tecnicamente

Conheça a abordagem da B10 Digital Agency para avaliar necessidades de software à medida, integrações e arquitetura de produto.

Conhecer software à medida e aplicações móveis →

Fontes e documentos relacionados

Estes documentos servem de referência para os métodos e regras abordados neste artigo.

B10 Digital Agency

Criar uma arquitetura multitenant para um produto SaaS