Rodamos a mesma arquitetura em 4 clientes. Cada um isolado. A decisão de não fazer multi-tenant — e quando a gente faz.
App Meta isolado · Edge própria · Tabela própria · Blast radius = 1 cliente · Multi-tenant onde faz sentido
O PostepTrack é o sistema que costura Meta Ads ao CRM do cliente. Quando alguém clica num anúncio do Facebook ou Instagram e cai no WhatsApp ou num formulário, o PostepTrack pega os identificadores que o Meta solta naquela janela e enxerta no lead que aparece no CRM minutos depois. Sem ele, o CRM mostra “origem: desconhecida”.
É uma Edge Function rodando no Supabase em Deno, escuta os webhooks da Meta, espera o lead aparecer no CRM e enriquece com campaign, adset, ad — tudo amarrado pelo ctwa_clid no caso do WhatsApp ou pelo leadgen_id no caso de Lead Ads. Texto pequeno, lógica curta. O complicado é tudo que está em volta.
Hoje rodamos isso em quatro clientes em produção. Cada um com sua instância separada: App Meta próprio, Edge própria, tabela própria. A pergunta que vem é sempre a mesma — por que não unificar.
No papel, o multi-tenant resolve. Uma Edge só, uma tabela só com coluna org_id, um App Meta da agência inscrito em todas as WABAs dos clientes. Mexeu num cliente, todos ganham. Bug num cliente? Você corrige uma vez. Deploy único.
→ A versão da esquerda é a que todo dev quer construir. A versão da direita é a que sobrevive em produção.
Cada motivo abaixo apareceu na prática, não no quadro branco. Quando você opera quatro clientes ao mesmo tempo, eles aparecem cedo.
Cliente A usa Kommo, B também usa Kommo mas com pipeline diferente, C usa Clint. Mesmo entre dois Kommos, os field IDs dos campos custom são números totalmente diferentes — o ctwa_clid de um é 802793, do outro é 1084178. Mapear isso por org num código só é fingir que dá certo até alguém renomear um campo.
Tecnicamente um App pode escutar várias WABAs. Na prática, cada cliente quer o App registrado em nome dele, com o Business Manager dele, e com tokens que ele controla. Um App único da agência centraliza um ponto de falha enorme: se o Meta suspende, todo mundo cai junto.
Quando o Vexo teve 83,6% de silent fail no branch leadgen, foi só o Vexo. Os outros três continuaram rodando intactos enquanto a gente debugava. Num multi-tenant, esse mesmo bug derruba a operação inteira de quatro empresas ao mesmo tempo.
Cliente novo entra copiando uma pasta, trocando quatro variáveis e fazendo um deploy. Não precisa abrir conversa sobre 'sua coluna org_id está aqui' nem renomear nada para não conflitar. O cliente existente nem sabe que outro entrou.
→ Nenhum desses motivos é teórico. Cada um custou tempo e dinheiro até a gente aprender a separar de verdade.
Separar tem preço. A gente paga em duplicação de código e em disciplina pra fix não ficar só num cliente. O truque é manter um template canônico e copiar dele.
A pendência fica visível porque a doc lista o que cada cliente já tem e o que falta replicar. Isso é o oposto de “escondemos a complexidade num if (org === X)”. Aqui a divergência é explícita — e pelo menos a gente sabe o que está rodando em cada lugar.
O custo de copiar é menor do que o custo de uma camada de abstração errada. E muito menor do que o custo de derrubar quatro clientes com um deploy ruim.
Pra ser honesto: a gente tem dois SaaS multi-tenant em produção também, com org_id e RLS de verdade. Eles existem porque o problema é outro.
→ Multi-tenant é uma escolha de produto, não de arquitetura. PostepTrack não é produto — é infraestrutura por cliente.
Pergunte se o sistema vive DENTRO da conta do cliente (token dele, CRM dele, Meta dele). Se sim, instância isolada vence multi-tenant antes mesmo de pensar em código.
Mantenha um template canônico. Quando um pattern emerge em 2+ clientes, promove pra template — o copiar fica disciplinado, não preguiçoso.
Fix nasce num cliente. Vira commit no template. Replica nos outros sob demanda. A pendência mora na doc, não num if escondido.
Blast radius é a métrica que mais importa em pipeline crítico. Um modelo que derruba quatro clientes ao mesmo tempo não vale o deploy único.
Multi-tenant é pra produto que você vende. Instância isolada é pra infraestrutura que vive dentro do cliente. Se você confundir os dois, paga em downtime — e o cliente paga junto.