Multi-tenancy preparada sem superdimensionar

Alternativas consideradas

Descartada

Assumir que a persistência sempre corresponde a um único banco de dados.

Escolhida

Preparar a camada de persistência para que essa suposição não fique incorporada ao código.

Decisão tomada

Centralizar o acesso a dados por meio de um contexto de tenant. O MVP usa um banco compartilhado, mas o código não depende dessa condição. A hierarquia considerada é tenant, empresa, filial e localização.

Justificativa

Permite começar com o escopo inicial e manter um caminho de crescimento para multiempresa e multifilial sem uma reescrita posterior.

Perguntas frequentes

O que a Pymerce decidiu sobre "multi-tenancy preparada sem superdimensionar"?

Centralizar o acesso a dados por meio de um contexto de tenant. O MVP usa um banco compartilhado, mas o código não depende dessa condição. A hierarquia considerada é tenant, empresa, filial e localização.

Qual é a diferença entre single-tenant e multi-tenant, e por que a Pymerce escolheu essa hierarquia?

No single-tenant, cada cliente fica isolado em seu próprio banco ou infraestrutura; no multi-tenant, os recursos são compartilhados entre clientes com isolamento lógico. A Pymerce define uma hierarquia de tenant, empresa, filial e localização, e resolve o acesso aos dados sempre pelo tenant, mesmo que o MVP use um único banco compartilhado.

Vale a pena cada cliente ter seu próprio banco de dados, ou dá para compartilhar um só?

Para o escopo inicial da Pymerce, compartilhar um único banco é suficiente e mais simples de operar. A decisão importante não é o banco em si, mas o fato de o código nunca partir dessa suposição: o acesso sempre passa pelo contexto de tenant, então migrar para bancos separados mais adiante não exige reescrever a camada de dados.

Quais são as desvantagens de preparar multi-tenancy já desde o MVP?

Isso adiciona uma camada de indireção (o contexto de tenant) que não seria necessária se o negócio nunca crescer para multiempresa. A Pymerce limita esse custo centralizando o acesso aos dados em um único ponto do código, em vez de construir isolamento físico ou infraestrutura separada que ainda não é necessária.