Compare recursos partilhados e separados em dados, tarefas e operação. Defina isolamento além de autenticar o utilizador.
Multi-tenancy permite servir várias organizações com um serviço. A questão central é onde partilhar recursos e como limitar acesso e carga. Autenticar o utilizador não define sozinho os recursos a que pode aceder. Trate isolamento como requisito de todos os percursos, incluindo suporte e processamento em segundo plano.
Escolher fronteiras pelos requisitos
| Modelo | Vantagem possível | Questão operacional |
|---|---|---|
| Tabelas comuns com identificador | Eficiência e migrações comuns | Como impor filtragem em todo o lado? |
| Esquemas ou bases separados | Fronteira de dados mais clara | Como gerir migrações e cópias? |
| Publicações separadas | Capacidade independente | Como operar uma frota crescente? |
Os modelos podem combinar-se. Partilhe controlo e isole uma carga com exigências diferentes quando justificado. Documente a razão e como selecionar o modelo na entrada de clientes. Bases separadas não garantem isolamento se credenciais, suporte ou exportações atravessarem a fronteira sem controlo.
Transportar contexto fiável
Resolva pertença e permissões no servidor. Um identificador enviado no pedido não prova acesso. Inclua contexto em tarefas, cache, caminhos de ficheiros e auditoria, verificando-o onde se acede ao recurso. Examine operações administrativas transversais separadamente e limite-as a finalidades explícitas.
- Criar contas de duas organizações de teste com dados distintos.
- Verificar leitura, alterações, exportações e ficheiros por função.
- Exercitar tarefas e cache após mudar contexto.
- Registar ator, organização e finalidade do suporte.
- Testar recuperação e eliminação segundo a fronteira.
Examinar isolamento de carga
Uma importação ou relatório dispendioso pode degradar outros sem expor dados. Defina quotas, agendamento ou separação quando necessário e meça com carga representativa. Mantenha inventário e aprovisionamento versionados para evitar exceções invisíveis. Reveja arquitetura quando clientes ou utilização mudarem.
Guarde provas por percurso e função. Uma única verificação não demonstra todo o sistema. Analise também recuperação: restaurar dados comuns tem consequências diferentes de restaurar apenas uma organização. Quem gere incidentes precisa de conhecer esse limite. Privacidade dos dados e estabilidade sob carga são aspetos relacionados, mas exigem evidências diferentes.
- Desenvolvimento SaaS
- Funcionalidades de um MVP SaaS: um percurso completo
- Due diligence técnica numa aquisição SaaS
Perguntas frequentes
Um identificador por tabela chega?
Não. Consultas, tarefas, cache, ficheiros e administração devem aplicar contexto fiável.
Cada cliente precisa da própria base?
Nem sempre. Decida por isolamento, recuperação, carga e operação.
Separação substitui autorização?
Não. Aplicação e operações continuam a precisar de permissões e credenciais controladas.
Como testar isolamento?
Com contas autorizadas distintas e verificações de leitura, escrita, exportação, tarefas e privilégios.
O que é um vizinho ruidoso?
Um cliente consome recursos comuns e degrada outros, mesmo sem fuga de dados.
Da ideia a um âmbito que se consegue executar
Partilhe o percurso do utilizador, integrações e condições de lançamento. Podemos preparar uma estimativa com pressupostos e exclusões.
Leitura complementar
Funcionalidades de um MVP SaaS: um percurso completo
Defina valor, separação de clientes e operação. Adie variantes sem deixar incompleto o primeiro resultado prometido pelo produto.
Due diligence técnica numa aquisição SaaS
Analise isolamento, faturação, custos e dependências de transferência. Ligue provas técnicas ao plano de aquisição e integração.
Integração de subscrições Stripe: checklist SaaS
Relacione faturação e acesso. Teste renovação, falhas, eventos repetidos e recuperação antes de ativar cobranças reais.