Design Pattern: Como arquitetar uma aplicação multi-tenant

Рет қаралды 18,798

Күн бұрын

Пікірлер: 41

@Ravekx Жыл бұрын

Na empresa onde trabalho, independente do cliente, grande/medio/pequeno, separamos por ID, usamos um master e 2 slaves, as operações de escrita são no master e as de leitura o balancer direciona para os slaves. Isso ajuda bastante a aliviar o master

@Legiaodohorror 7 ай бұрын

Pode me explicar melhor como funciona essa técnica? Estou pensando em criar um software, achei interessante essa abordagem

@stelvyanselmo Ай бұрын

De igual modo podia explicar melhor como usar essa técnica? Entre o master e o slave?

@joaoluismoraes7215 Жыл бұрын

Eu tenho um SaaS para clinicas médicas e recentemente migrei pra multitenant. Antes, precisava criar uma aplicação diferente pra cada nova clínica. A maneira que faço é dentro de uma mesma instância do banco, crio 1 schema pra cada clinica nova. E, nas requisições, mando o tenant id sempre pra diferenciar.

@gfrsolutions8042 Жыл бұрын

Vc trabalha com o mesmo banco mas cria uma tabela para cada cliente ?

@joaoluismoraes7215 Жыл бұрын

@@gfrsolutions8042 Mesmo banco, mas diferentes schemas pra cada cliente. O conceito de schema no Postgres é como se fosse um namespace. Cada cliente tem suas tabelas, procedures, triggers etc... mas tudo dentro do mesmo banco.

@soft.developer Жыл бұрын

@@joaoluismoraes7215tu desenvolveu do zero mano? Ou foi low fode/no code? Se não, quais tech usou? Se puder falar, claro

@ditimarf 7 ай бұрын

O ponto negativo dessa arquitetura seria ter que alterar todos os schemas ao fazer uma alteração de BD, certo? Como voce faz para evitar isso?

@joaoluismoraes7215 7 ай бұрын

@@ditimarfponto negativo, mesmo. provavelmente teria que rodar migrations. justamente por isso nós mudamos a estratégia: agora é um banco só e separamos por tenant_id na tabela. facilita bastante!

@douglasoliveira2119 Жыл бұрын

Muito bom o vídeo, mas será que não rola um outro vídeo com foco no código de como ficaria uma aplicação nessa arquitetura? Algo mais básico mas que fosse um ponto de partida...

@jarodcavalcante Ай бұрын

nas entidades vc coloca um tenantID, daí tudo será relacionado à esse tenantID

@jucelinofilho9404 Жыл бұрын

Já trabalhei em vários produtos Saas, e sem dúvida a melhor opção foi usando microservicos. Tínhamos um serviço exclusivo para administrar os tenants e gerênciar a autentiação e autorização deles. Cada microservicos tinha seu próprio database e separavamos os tenants por schema (Postgres)

@Legiaodohorror 7 ай бұрын

Pode me explicar melhor como funciona isso? E onde posso aprender mais, quero fazer algo assim para meu saas

@wgwalisongomes Жыл бұрын

Passei a adotar o modelo de um banco para cada cliente. Tenho um banco onde salvo as informações de autenticação de cada cliente (meu) e identifico quem tá usando o sistema pelo subdomínio. Quando o cliente acessa o sistema eu verifico de quem se trata, carrego as informações dele para um redis (para evitar essa consulta o tempo todo) e a partir daí a conexão com o banco de dados é feito de forma dinâmica. Consigo assim permitir até que o cliente hospede o banco de dados em um servidor próprio se achar necessário.

@montmor123 11 ай бұрын

Cara eu to estudando isso, mas não entendi muito bem fomo é feito essa distinção antes de logar na aplicação. Imagina que eu tenho um portal onde o usuario loga, eu teria um banco "Geral" pro cliente logar e eu saber qual seria a empresa dele? e ai como eu laço esse usuario no banco da empresa? esses detalhes que me pegaram xD.

@zoiaonline 10 ай бұрын

@@montmor123 No caso vc teria um banco de dados "seu" com todos os seus inquilinos nele (email, senha,...etc, nome_do_banco, ip_do_banco), como se fosse um banco de dados so pra autenticacao, e um microserviço de autenticao que retornara o token e dai pra frente a aplicacao em si ira saber qual o inquilino e qual o banco dele, naum sei se fui claro

@montmor123 10 ай бұрын

@@zoiaonline Obrigado amigo vc é um amigo!

@brunoandrade6825 Жыл бұрын

Show demais mestre. Aqui na empresa usamos o Dynamo e separamos logicamente apenas utilizando a estratégia da PK.

@williamsantos4819 Жыл бұрын

Otimo conteudo, hoje temos os 2 cenarios multiplos databases e o tenant_id nas tabelas então temos opção de ter um banco para clientes de pequeno porte onde segregamos um numero x de clientes por banco de dados e também bancos totalmente separados para clientes de medio e grande porte

@cadu172 9 ай бұрын

Na empresa implementamos com o multi database porque existem customizações inerentes ao negócio de cada cliente, uma base central que serve de template e filhos que herdam suas características, o que é inerente de cada negócio modificamos somente na base e implementamos na aplicação através de interfaces.

@artu_almeida Жыл бұрын

que legal, eu ja trabalhei com uma aplicacao multi-tenant e nem sabia! construimos um SaaS na empresa, o produto era comercializado para os clientes, pay-per-use era um gerador de assinaturas de email, o cliente criava uma assinatura, e aplicava no email corporativo para todos os usuarios o sistema nao era de grande porte, era uma API rest monolita em java/spring, o front era em vue.js, e ambos rodavam no PaaS do GCP (em maquinas diferentes) e o banco de dados era apenas 1, era cloud firestore, banco NoSQL do GCP, ate hoje me pergunto se escolhemos o banco certo... Sempre achei que tivesse sido um erro essa escolha, e que deveria ser SQL padrao, mas agora assistindo o video, talvez essa escolha de usar NoSQL faça sentido, se tratando de uma app multi-tenant

@walissonwaal 5 ай бұрын

Neste exato momento estou atuando em um SaaS pessoal onde implementei a metodologia Multi-Tenant.

@marcosoliveira8731 Жыл бұрын

Muito bom. Não sabia de muitos pontos que apresentou.

@avinicius.adorno Жыл бұрын

Uso um banco de dados para cada cliente, e separo o acesso por subdomínio

@joaobatista-rn6le Жыл бұрын

Legal, qual estratégia vc usa para isolar as autorizações dos clientes?

@avinicius.adorno Жыл бұрын

@@joaobatista-rn6le a parte de autorização e autenticação fica no banco de dados do cliente, pois cada cliente configura os usuários e suas respectivas autorizações. Tenho um banco de dados mestre onde fica as configurações dos Tenants.

@brunofontana7795 Жыл бұрын

@@joaobatista-rn6le Também tive essa mesma dúvida, comentei pra acompanhar a resposta do Bones! hahahaha

@joaobatista-rn6le Жыл бұрын

@@brunofontana7795 boa, aguardemos kkkk

@eltonoliveira-ma Жыл бұрын

@@joaobatista-rn6lemas já não é isolado pelo banco?

@andrebonatti5073 Жыл бұрын

Não trabalhei com tabelas, penso que pra ter o trabalho de balanceamento e rastreio do tenant teria que marcar em muitos lugares, novos schemas ou data base acho mais apropriado pra esse tipo de arquitetura. Mas aquela velha nenhuma empresa nasce grande senão todos teriam microservice, docker, ambientes (dev/hom/prod), redundância e com monitoramento pesado pra tudo isso SLA 99,99%, mas quem iria pagar tudo isso se pode fazer um monolito que atende dentro de VPS e que custa 1/50 disso 🤷‍♂️ antes de pensar em todo essa arquiterura digna do coliseu, se o seu cliente só tá pedindo uma casa de 100m2

@jvidalnunes Жыл бұрын

Top demais!! Achei essa abordagem de 1 db para pequenas e médias e outro para cada grande empresa muito top. Tenho uma duvida: no caso desse 1 db para pequenas e médias, pensando no isolamento dos dados, poderíamos usar schemas para cada empresa? Sei que pode parecer troca 6 por meia dúzia visto que terão que ser criadas as tabelas de novo, mas não há nenhum ganho ao utilizar esse recurso?

@jvidalnunes Жыл бұрын

Outra dúvida, pensando nas particularidades que cada cliente possa ter.. a decisão de negócio mais sensata seria rejeitar novas funcionalidades que vão atender apenas poucos clientes. Mas em um caso diferente, como gerenciar essas mudanças tanto de banco, quanto de aplicação para alguns clientes?

@rntbczk Жыл бұрын

Atualmente eu trabalho no modelo de primary key, mas temos um problema muito grande pois as aplicacoes backend sao java 8 e muitos clientes juntos. Temos problemas constantes de vazamento de memoria mesmo sendo microservices. O backend consome quase 80gb de ram diariamente na AWS. Estamos buscando formas de conseguir desacoplar mais a aplicacao e buscando alternativas mais leves como nodejs, onde conseguimos consumor menor de ate 90% de memoria usando 20 replicas para aguentar a quantidade de requests feitas. Sao quase 100k US$ por mes so de infra

@diego.almeida Жыл бұрын

acho que golang seria mais adequado, go é bem mais eficiente em termos de memória que nodejs, usa metade. E é muito fácil de implementar concurrency. Go é mais rápido tmb, atende mais requests/second. Pelo tamanho do seu serviço, usar Go iria reduzir bem o custo de infraestrutura.

@leonardoperes-so1nc 9 ай бұрын

Pelo que eu entendi, no modelo de PK, o tenant_id sempre vai na PK de outras tabelas. Desta forma, Quando eu criar uma tabela que se relaciona com outra tabela (por exemplo itens do produto), eu referencio o tentant_id como chave estrangeira da tabela de tenant , ou da tabela de produto, já que eu também vou ter que referenciar ela?

@devborges 9 ай бұрын

quero entender mais, pois estou montando uma api que vai ser pra multi-tenant então, quero saber se é melhor separar por banco

@Oculterous Жыл бұрын

Qual a diferença para uma aplicação white label?

@programadorPragmatico42 Жыл бұрын

Na empresa que trabalho, separamos por esquemas do banco de dados

@cristianomachado3687 Жыл бұрын

Olá obrigado pela aula e conhecimento, uma duvida, alguns bancos permite o uso de schemas, sei que a finalidade não é essa, mais o uso é muita gambiarra ? abs ...