Arquitetura e Projetos · Vinnicius Santos — Decisões de arquitetura em SaaS multi-tenant

Arquitetura e Projetos · Vinnicius Santos — Decisões de arquitetura em SaaS multi-tenantEstudos de caso de Vinnicius Santos: decisões de arquitetura, segurança e deploy em SaaS multi-tenant com C#/.NET, Next.js e PostgreSQL, com os trade-offs de cada escolha.Arquitetura, para mim, é a soma das decisões que ficam caras de mudar depois. Por isso registro o que escolhi, por que escolhi e o que deixei de lado em cada projeto, incluindo a dívida técnica que assumi de propósito.PendurAi — PDV e ERP SaaS multi-tenant para adegas e mercadosSistema de frente de caixa e retaguarda vendido para várias lojas, com cobrança recorrente por loja.

Schema único com isolamento por tenant_id. Todas as lojas compartilham o mesmo schema, e o tenant é aplicado em toda consulta por um provedor de tenant. Reduz custo e simplifica a operação; em troca, o isolamento depende da disciplina da aplicação.

Dapper e Npgsql no caminho transacional. A venda grava estoque, venda e ledger em uma única transação atômica, então escolhi controle direto de SQL e transação. O cliente REST do Supabase ficou restrito à autenticação.

Ledger imutável e caixa cego. Sangria e suprimento só entram como lançamentos novos, e o operador conta o caixa sem ver o saldo esperado. A quebra de caixa aparece sozinha, sem depender de confiança.

Webhooks com fila durável. Pedidos do Zé Delivery entram em fila e são processados por um serviço em segundo plano, com assinatura HMAC e rate limiting. Um pico ou uma falha não derruba o PDV nem perde pedido.

Licença controlada pelo pagamento. O webhook do Asaas atualiza o status da licença, e o login é bloqueado quando ela está suspensa, cancelada ou expirada.

MarcAi — Plataforma SaaS de agendamento para salões de estéticaUma única aplicação atende vários salões, cada um com subdomínio, equipe, agenda e financeiro próprios.

Tenant resolvido pelo subdomínio. Um middleware resolve o salão pela URL e guarda o resultado em cache por 60 segundos. O cookie de sessão é restrito ao host e carrega o tenant, conferido contra a URL a cada requisição.

Conflito de horário bloqueado no banco. Uma constraint EXCLUDE no PostgreSQL impede dois agendamentos sobrepostos, e um trigger reforça a regra de cancelamento. A validação em C# existe, mas não é a última barreira.

2FA via TOTP implementado do zero. O algoritmo da RFC 6238 foi escrito sem pacote externo e validado contra os vetores oficiais da RFC, para entender e testar o que protege o painel do superadmin.

TLS wildcard por desafio DNS-01. Como cada salão tem um subdomínio, o certificado precisa ser wildcard, e o desafio HTTP-01 não cobre esse caso. O Caddy emite o certificado via DNS.

Portal de Governança de TI — Sistema interno de acessos, hardware, telefonia e conhecimentoCentraliza solicitações de acesso, inventário, linhas corporativas e políticas que antes ficavam em planilhas.

A aplicação é o único cliente do banco. A primeira versão usava Row Level Security no Supabase. Migrei para um Postgres próprio, com a autorização explícita no código em cada leitura e escrita, para não depender de plataforma de terceiros.

Defesa em profundidade com triggers. Campos imutáveis após a criação, bloqueio de autoescalonamento de privilégio e motivo obrigatório em toda recusa são garantidos pelo banco.

Auditoria escrita só por trigger. Toda escrita relevante gera log por trigger, e nenhum código de aplicação grava na trilha diretamente.

Sessão própria e revogável. Token opaco em cookie HttpOnly, Secure e SameSite=Strict, validado contra uma tabela de sessões. Desativar uma conta derruba o acesso na hora.

Mocidade 015 — Reserva de assentos em ônibus para viagens em grupoParticipantes escolhem o ônibus pelo terminal de saída e marcam o assento em um mapa, com lista de espera.

Reserva em transação Serializable. Reservar, cancelar e atribuir vaga rodam no nível de isolamento mais alto, o que impede dois participantes de ficarem com o mesmo assento.

Segredos fora do repositório. A connection string nunca fica no arquivo de configuração: vem de variável de ambiente ou de user secrets.

Deploy automático a cada push. O GitHub Actions publica a aplicação, envia os arquivos por rsync e reinicia o serviço systemd. Um Dockerfile cobre a execução em container.

Life OS — Painel pessoal de rotina, treinos, alimentação e estudosFerramenta de uso diário, com contas individuais e documentação de arquitetura versionada junto do código.

Decisões registradas em ADRs. Escolha de stack, modelo de autenticação e estratégia de build estão em Architecture Decision Records no repositório.

Build fora do servidor. A imagem Docker é gerada no GitHub Actions, e não na EC2, para não disputar memória e CPU com as aplicações em produção.

Row Level Security por usuário. Os dados são isolados por policies no Postgres, e o site institucional é a única parte pública.

Agenda Osvair — Agendamento online para transporte executivoO cliente solicita um horário, recebe o orçamento e aprova antes de a corrida entrar na agenda.

Sem servidor de aplicação. O front estático fala direto com o Supabase, protegido por RLS. O deploy é cópia de arquivos, e o custo de operação é mínimo.

Regras de negócio em funções do banco. Como não há backend próprio, as regras ficam em funções RPC do Postgres, e não no navegador.

WhatsApp por link universal. O orçamento segue por link wa.me, sem custo de API de mensageria.

Arquitetura e projetos

Sobre

Ferramentas

GitHub