Plataforma multi-tenant para rede de franquias

O contexto

Rede de 12 franquias no setor de serviços operando com planilhas independentes por unidade. A matriz não tinha visão consolidada de faturamento, estoque ou performance. Cada franqueado usava ferramentas diferentes — alguns no Excel, outros em ERPs baratos, outros no papel.

O problema

• Zero visibilidade para a matriz — relatório consolidado exigia ligar para cada unidade
• Risco de vazamento de dados — um franqueado poderia acessar informações de outro
• Retrabalho massivo — mesmos cadastros (produtos, fornecedores) digitados 12 vezes
• Decisões no escuro — sem dados comparativos entre unidades, impossível identificar oportunidades

A solução técnica

Arquitetura multi-tenant com Row-Level Security

Optamos por banco único com RLS (Row-Level Security) no PostgreSQL. Cada registro pertence a um tenant_id e as políticas de segurança impedem consultas cross-tenant em nível de banco — não só de aplicação.

Sistema de permissões em dois níveis

• Nível tenant (dentro da franquia): admin local, operador, viewer
• Nível rede (acima dos tenants): super-admin matriz, auditor, financeiro rede

Módulos implementados

1. Cadastro unificado — produtos e fornecedores centralizados pela matriz, customizáveis por unidade
2. Estoque por unidade — com alerta de mínimo e sugestão de reposição
3. Financeiro — contas a pagar/receber por franqueado + consolidado da rede
4. Dashboard matriz — ranking de unidades, comparativos, alertas operacionais
5. Trilha de auditoria — cada operação registra quem, quando, de qual tenant

Stack

PostgreSQL (RLS) | Node.js | React | Docker | AWS (ECS + RDS)

O resultado

Métrica	Antes	Depois
Tempo para relatório consolidado	3-5 dias	Tempo real
Cadastros duplicados	~2.400	0
Horas de retrabalho/semana (rede)	~35h	~4h
Incidentes de dados vazados	2 em 6 meses	0 em 12 meses

Aprendizados

• RLS é poderoso mas exige disciplina — todo teste automatizado deve validar isolamento. Criamos uma suite específica que tenta acessar dados cross-tenant a cada deploy.
• Migração gradual funciona melhor — migramos 3 unidades primeiro, validamos, depois as outras 9 em lotes de 3.
• Matriz precisa de produto próprio — o painel da matriz não é "mais uma unidade", é um produto com necessidades diferentes (comparativos, benchmarks, alertas).