A plataforma
Uma base compartilhada, e nenhum dado compartilhado.
Os módulos da IMPERIO não são sistemas independentes que se parecem. São aplicações sobre a mesma camada de identidade, cadastro, cobrança, base de regras e auditoria — o que muda de um para o outro é o domínio, nunca a fundação.
Por que isso importa para quem compra
No dia em que o módulo Fiscal tiver o próprio login e o de Licitações tiver outro, deixamos de ter um produto e passamos a ter dois — com o dobro do suporte e metade do valor percebido. O cliente entra uma vez, com um cadastro e uma fatura, e enxerga os módulos que o plano dele libera.
O caminho de uma requisição
Quatro perguntas antes de o módulo ver o pedido.
A borda resolve tudo antes de o código do módulo rodar. Ele recebe um contexto pronto e uma conexão já apontada para o banco certo — e nunca reverifica nada, porque resolver duas vezes é a receita para as duas resoluções divergirem um dia.
-
De qual cliente é este endereço?
O subdomínio vira o identificador do contratante. É a única fonte legítima dessa informação — nunca o corpo da requisição, a query string ou um cabeçalho.
-
Este cliente pode entrar?
O cadastro central responde a situação do contrato e devolve o endereço do banco dele. Cliente congelado ou removido para aqui.
-
O usuário é deste cliente?
O token diz de qual cliente a pessoa é. Se divergir do subdomínio, a requisição é recusada e o evento vira incidente de segurança.
-
O plano inclui este módulo?
A contratação responde. O módulo não decide se pode ser acessado — ele pergunta.
Endpoint sem anotação de autorização não nasce aberto: ele nasce quebrado, e responde erro 500 no primeiro teste. Abrir um endpoint ao público tem que ser um ato deliberado que aparece no diff.
As decisões que sustentam o resto
-
Isolamento por banco de dados
Cada cliente opera sobre um banco PostgreSQL dedicado, na mesma instância gerenciada — isolamento real sem pagar uma instância por cliente. Há teste automatizado que faz a mesma pergunta no banco do vizinho e exige resposta vazia. A linha que decide o que vai para o banco do cliente é uma pergunta só: se isso vazasse para outro contratante, seria um incidente?
-
Módulo liberado é módulo assinado
O plano concede o direito de usar determinados módulos, e esse direito é histórico, não um sim-ou-não. Cada decisão registra quem ligou ou desligou, quando, até quando e por quê — porque a pergunta “por que este cliente perdeu o módulo de Transação em março?” sempre chega. São cinco situações possíveis, e cada uma leva a uma conversa diferente.
-
Regra tributária com vigência e fundamento
Alíquota, redução de base e critério de enquadramento são dado versionado, com período de validade, base legal e homologação declarada — não constante espalhada pelo código. A resposta carrega o carimbo da versão que a produziu, e não existem duas regras válidas na mesma competência: se existissem, o resultado dependeria da ordem de iteração, e “mesmo documento, mesmo resultado” viraria sorte.
-
Operação classificada por risco, antes do papel
Toda operação é classificada por uma pergunta: se isso for feito errado, o que acontece? Leitura não muda nada. Operação se conserta refazendo. Sensível vai para relatório que alguém assina. Crítica não se desfaz sozinha. Só depois disso um papel recebe permissão — e sensível e crítica sempre deixam rastro, mesmo quando autorizadas.
-
Custo mínimo como requisito de engenharia
A plataforma foi desenhada para não gastar parada: os serviços escalam a zero quando ninguém está usando e o banco desliga fora do horário de trabalho. Não é economia aplicada depois — é restrição de projeto desde o primeiro commit, e é o que torna a assinatura previsível para quem contrata.
Controle de acesso
Quatro níveis de risco, duas hierarquias.
Emitir uma guia e desligar o módulo de um cliente não podem estar no mesmo balaio. A classificação vem antes da permissão, e não o contrário.
| Nível | Consequência do erro | Exemplos |
|---|---|---|
| Leitura | nada muda | ver carteira, ver empresa, ver relatório, ver trilha |
| Operação | se conserta refazendo | emitir guia, anexar comprovante, simular |
| Sensível | vai para relatório que alguém assina | homologar regra tributária, registrar adesão a acordo, trocar certificado |
| Crítica | não se desfaz sozinho | remover cliente, ligar ou desligar módulo, revogar sessão, administrar equipe |
As hierarquias do cliente e da IMPERIO são separadas, e a guarda trata cada uma por uma porta. Não existe escada única em que um administrador de cliente muito graduado chegue perto do suporte da plataforma — são mundos diferentes.
Capacidades compartilhadas
O que todo módulo recebe pronto.
Nada disso é reescrito dentro de um módulo. Duplicar identidade, cobrança ou controle de acesso é o que mata uma plataforma.
-
Identidade e sessão
Papéis separados por nível de risco, política negativa por omissão, sessão revogável sem esperar o token expirar, e o tempo entrando como parâmetro — nada lê o relógio da máquina, porque regra de prazo que ninguém consegue testar é regra que ninguém confere.
-
Isolamento por cliente
Resolução do cliente pelo endereço, contexto explícito que não se propaga sozinho entre threads, e um conjunto de subdomínios reservados que nunca podem ser cliente — um cliente chamado “admin” receberia requisição destinada ao painel interno.
-
Cadastro por CNPJ
Empresa cadastrada a partir dos dados abertos da Receita Federal, com dígito verificador conferido antes da consulta e o CNAE normalizado na borda. CNAE digitado errado não dá erro: dá recomendação errada com cara de certa.
-
Base de regras tributárias
A mesma base serve o simulador, o classificador da Reforma e o auditor de documentos. Se nascesse dentro de um módulo, os outros dois duplicariam — e teríamos a mesma regra mantida em três lugares.
-
Índices oficiais
Selic direto da série do Banco Central, com memória de cálculo. A acumulada é soma, não capitalização — é o que a legislação tributária manda, e capitalizar daria um número maior e errado para este fim. Mês ainda não fechado é projeção declarada, nunca cálculo.
-
Contratação e trilha
Histórico de módulos por cliente, gravado em tabela que recusa alteração e exclusão no próprio banco — não por disciplina da aplicação. Corrigir é acrescentar um evento, nunca reescrever o anterior.
Arquitetura
As camadas, de fora para dentro.
Tela e API são servidas da mesma origem, o que dispensa balanceador e segundo domínio. Abaixo, o que existe em cada andar.
-
Borda
Hospedagem estática com CDN e certificado gerenciado, na mesma origem da API.
-
Aplicação
Serviços em contêiner, provisionados sob demanda e sem instância ociosa.
-
Plataforma
Identidade, tenancy, cadastro, cobrança, base de regras, índices e auditoria, compartilhados por todos os módulos.
-
Dados
Um PostgreSQL por cliente, cifrado em repouso, com migração versionada e restauração testada.
-
Integração
Fontes oficiais primeiro: Banco Central, dados abertos do CNPJ, PNCP. Conector de portal só depois de verificação jurídica por órgão.
-
Operação
Infraestrutura declarada, integração contínua e regras de arquitetura que quebram o build quando violadas.
Duas aplicações, propósitos opostos
Não é uma aplicação com perfil de administrador. São duas, porque público, risco e superfície de ataque são diferentes — e um erro de autorização numa aplicação única significaria cliente enxergando cliente, o pior desfecho possível num produto que vende isolamento.
-
Portal do cliente
Onde o contratante trabalha, sob o subdomínio dele — escritório de contabilidade ou empresa, o mecanismo é o mesmo. Vê os módulos que assinou, os próprios dados e nada além.
-
Painel da IMPERIO
Onde a nossa equipe administra contratos e assinaturas. Age sobre os clientes, não dentro de um: não há subdomínio de cliente, o acesso é restrito ao domínio corporativo e cada ação aprovada vira evento na trilha.
O ciclo de vida do cliente, e a diferença que importa
Quatro estados, e a distinção entre eles é deliberada. Só o último não tem volta — e o botão dele só habilita depois da saída lógica.
| Ação | O que faz | Reversível | Dados |
|---|---|---|---|
| Ativo | operação normal | — | intactos |
| Congelar | bloqueia o acesso, mantém tudo | sim, imediato | intactos |
| Remover | saída da operação, exclusão lógica | sim | intactos |
| Excluir dados | apaga o banco do cliente | não | destruídos |
A exclusão física existe por causa da LGPD — o titular tem direito à eliminação —, não por conveniência operacional. Exige confirmação por escrito e registra quem executou.