Construindo o Luma: multi-tenant seguro com Supabase, RLS e automações com IA
Como isolar os dados domésticos de cada família sem sobrecarregar a camada de aplicação. A implementação de Row Level Security (RLS) no PostgreSQL, a integração com webhooks do n8n para inteligência artificial e a lição de nunca confiar no código para filtrar permissões de banco.
O Luma nasceu de um desafio que parecia simples na teoria e assustador na prática: construir um aplicativo de gestão doméstica compartilhada — tarefas, despensa, contas e finanças — onde várias famílias usam o mesmo sistema, mas o isolamento entre elas precisa ser matematicamente inviolável. Em um aplicativo desse tipo, um único vazamento que mostre as tarefas ou finanças de uma família para outra destrói toda a credibilidade do produto.
No início, a tentação clássica é colocar a responsabilidade de isolamento na aplicação: adicionar uma coluna 'household_id' em cada tabela e lembrar de escrever 'WHERE household_id = @atual' em todas as consultas SQL do repositório. Essa é a receita clássica de desastre. Mais cedo ou mais tarde, em uma consulta com cinco JOINs escrita às duas da manhã, alguém esquece a cláusula em um subselect e o vazamento acontece.
RLS como fonte absoluta da verdade
Decidi que a segurança do Luma não dependeria da disciplina do desenvolvedor, mas das leis da física do banco de dados. Adotamos o Supabase com Row Level Security (RLS) habilitado em 100% das tabelas. No RLS, você escreve políticas declarativas que o próprio motor do PostgreSQL executa internamente antes de devolver qualquer linha.
A regra básica é elegante: uma política como 'auth.uid() IN (SELECT user_id FROM household_members WHERE household_id = tasks.household_id)' garante que, mesmo se um programador cometer o erro crasso de rodar 'SELECT * FROM tasks', o PostgreSQL simplesmente não enxerga nenhuma linha que não pertença à casa do usuário autenticado. A segurança se torna invariante por padrão.
Segurança multi-tenant confiável reside no kernel do banco de dados, nunca na disciplina de quem escreve a API.
Do trigger no banco à ação de IA no n8n
Isolamento de dados é apenas a base; o valor real do Luma aparece quando a automação com IA entra em cena. Em vez de criar rotinas pesadas de polling que checam o banco a cada minuto, conectamos o Supabase Database Webhooks diretamente ao n8n.
Quando um membro da família adiciona um item à despensa ou registra uma compra recorrente, o PostgreSQL dispara um evento assíncrono via webhook para o n8n. O workflow deduplica a requisição, formata o contexto e aciona um agente especializado via Model Context Protocol. O agente analisa o histórico da casa, prevê reposições e gera notificações contextuais no celular da família antes que o produto acabe.
O que a arquitetura do Luma me ensinou
Construir o Luma consolidou uma convicção que aplico em todos os meus projetos de engenharia: arquiteturas enxutas e inteligentes delegam responsabilidades para as ferramentas certas. O banco de dados cuida de integridade e segurança de acesso; o n8n cuida de orquestração de eventos; e a IA entra exclusivamente para raciocinar sobre dados estruturados. Nenhuma peça tenta fazer o papel da outra, e o sistema escala com estabilidade.