Neste artigo
- Por que isso é decisão de negócio, e não só técnica?
- Decisão 1: como os clientes são separados?
- Decisão 2: onde o isolamento é garantido?
- Decisão 3: o que responde na hora e o que vai para fila?
- Decisão 4: onde mora o estado?
- Decisão 5: como o schema evolui?
- O que isso custa quando é ignorado?
- Perguntas frequentes
Cinco decisões de arquitetura tomadas na primeira semana definem o custo de operar um SaaS pelos três anos seguintes: como os clientes são separados, onde o isolamento é garantido, o que é assíncrono, onde mora o estado e como o schema evolui. Todas são baratas agora e caras depois, e nenhuma aparece na tela para o usuário.
Por que isso é decisão de negócio, e não só técnica?
Quem contrata software costuma ser convidado a opinar sobre tela e ignorado nas decisões acima. É o contrário do que deveria: tela se muda em uma tarde, modelo de isolamento de dados se muda com migração, janela de indisponibilidade e risco.
Você não precisa escolher a implementação. Precisa saber que a escolha existe, e exigir que o fornecedor justifique a dele.
Decisão 1: como os clientes são separados?
| Modelo | Isolamento | Custo por cliente | Quando faz sentido |
|---|---|---|---|
| Coluna de tenant | Lógico, depende do código | Muito baixo | Maioria dos SaaS |
| Schema por cliente | Bom | Médio | Exigência de separação, poucos clientes grandes |
| Banco por cliente | Alto | Alto | Setor regulado, cliente que exige por contrato |
A pergunta a fazer ao fornecedor: se um cliente exigir que o dado dele fique em banco separado daqui a um ano, o que precisa acontecer? Se a resposta for “reescrever boa parte”, você aceitou um limite comercial sem saber.
Decisão 2: onde o isolamento é garantido?
Existe diferença enorme entre “o código filtra por cliente” e “o banco recusa se faltar o filtro”. A primeira depende de todo desenvolvedor lembrar, para sempre. A segunda transforma esquecimento em erro, não em vazamento.
É o defeito de segurança mais comum em SaaS, e o mais caro quando acontece, porque não é bug, é incidente com dado de cliente.
Decisão 3: o que responde na hora e o que vai para fila?
Relatório pesado, e-mail, integração com terceiro lento e processamento de arquivo não podem travar a tela do usuário. Se tudo for síncrono, o sistema funciona na demonstração e engasga no uso real.
Sintoma típico: “o sistema fica lento no fim do mês”. Quase sempre é operação pesada rodando no mesmo caminho da navegação.
Decisão 4: onde mora o estado?
Sessão, arquivo enviado e trabalho em andamento precisam viver fora do servidor de aplicação. Isso é o que permite crescer colocando mais máquinas, e o que permite reiniciar sem perder nada.
Quando essa decisão é ignorada, o sistema roda em uma máquina só, e o dia em que precisar de duas vira projeto.
Decisão 5: como o schema evolui?
Todo sistema muda. A pergunta é se a mudança de banco é controlada, versionada e reversível, ou se é alguém alterando tabela na mão em produção.
A pergunta ao fornecedor: como vocês fazem uma mudança de estrutura de banco com o sistema no ar? Se não existir resposta com etapa e caminho de volta, existe risco todo mês.
O que isso custa quando é ignorado?
Não é teoria. Os três cenários que eu mais vejo em sistema herdado:
- Isolamento só no código, e o dia em que um
WHEREfoi esquecido em um relatório novo - Tudo síncrono, e a operação inteira lenta no fechamento do mês
- Estado no servidor, e a impossibilidade de escalar sem reescrever a camada de upload e sessão
Os três se resolvem com uma decisão escrita na primeira semana, e custam caro em qualquer semana depois.
Perguntas frequentes
Preciso entender isso pra contratar?
Precisa saber que existem, e exigir que o fornecedor explique a escolha dele em português. Se ele não conseguir explicar sem jargão, provavelmente não decidiu, herdou.
Isso não encarece o projeto?
Decidir não encarece, são horas de conversa. O que encarece é decidir errado e descobrir com cliente dentro.
E pra um MVP?
Continua valendo, com escolhas mais simples. A diferença entre MVP bem arquitetado e mal arquitetado não é quantidade de infraestrutura, é ter as cinco respostas escritas. Peça um diagnóstico e a gente responde as cinco com o seu caso na mesa.
